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PREFACE 


The McDonnell Douglas Astronautics Company has been engaged in a Space Station 
Data System Analysis/Architecture Study for the National Aeronautics and Space 
Administration, Goddard Space Flight Center. This study, which emphasizes a 
system engineering design for a complete, end-to-end data system, is divided 
into six tasks: 

Task 1. Functional Requirements Definition 

Task 2. Options Development 

Task 3. Trade Studies 

Task 4. System Definition 

Task h. Program Plan 

Task 6. Study Maintenance 

This report contains the results of Task 3. Trade Studies resulting from 
Options Development (Task 2) were performed to aid in System Definition (Task 
4). 

McDonnell Douglas was assisted in Task 1 by the Ford Aerospace and 
Communications Corporation, IBM Federal Systems Division and RCA Government 
Systems Division. 

This report was prepared for the National Aeronautics and Space Administration 
Goddard Space Flight Center under Contract No NAS5-28082 as a part of Task 3 
activities . 

Questions regarding this report should be directed to: 

Glen P. Love 
Study Manager 

McDonnell Douglas Astronautics Company 
Huntington Beach, CA 92647 
(714) 896-2292 
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TASK 3 - TRADE STUDIES 


INTRODUCTION 


The primary objective of Task 3 is to provide additional analysis and insight 
necessary to support key design/programmatic decision for options 
quantification and selection for system definition. This includes: (1) the 

identification of key trade study topics, (2) the definition of a trade study 
procedure for each topic (issues to be resolved, key inputs, 
criteria/weighting , methodology), (3) conduct tradeoff and sensitivity 
analysis, and (4) the review/verif ication of results within the context of 
evolving system design and definition. 

Trade studies represent a systematic mechanism for deriving preferred 
alternatives within a specific domain of interest. These domains of interest 
(trade study topic) may be quite global in nature (i.e., standardization) and 
cut across many technology/design boundaries or highly localized to focus on a 
specific design problem. Such considerations must be organized into a logical 
and structured framework to facilitate trade study scheduling, integration 
(both with other trade studies and with system design needs), and 
validation. This framework is the systematic design approach shown in Figure 
1 where trade studies are directly supportive of architectural needs both in 
scope and level of design detail. Trade studies provide the insight within 
specific domains of interest to support the stepwise ref inement of design 
detail. This approach promotes interaction between successive design steps 
and provides enhanced visibility/traceability for key decisions. 

Trade study topics are actually "domains of interest" that include a number of 
interrelated issues that cannot be easily "decoupled" or form a logical 
technology related subset. These topics may include one or more "tradeoffs" 
that attempt to resolve the key issues identified. The primary source of 
trade data was developed under Task 2 (options development). This required an 
integrated Task 2/3 approach to insure that all trade study objectives were 
achieved . 
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Key Trade Studies 
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Figure 1. Relationship Between Trade Studies and System Desigi 






In general, trade studies have many aspects that are quite unique to the 
specific topic. These unique aspects are dictated by design/programmatic 
needs as well as the nature of the issues to be addressed. However, these 
needs are addressed within the framework of a systematic trade study 
methodology. This includes the following fundamental concepts. 

1. The establishment of a set of generic trade criteria as guidelines to 
be applied to all trade study areas (see Table 1). Trade study 
unique criteria will be developed within the context of each area and 
will include all relevent Task 1 requirements . 

2. The development of trade study definition reports (work packages) 
that can be reviewed prior to conduct of the study. 

3. Adherence to sound system engineering practices that includes 
traceability to requirements and sensitivity analysis. 

4. Extensive peer group review. 

TASK APPROACH 

This section will describe the steps that define the task methodology and 
approach. The key steps include: 


1 . 

Identify/Prioritize Trade Study 

Topics 

2. 

Develop Individual Trade Study 

Definition Workpack&ges 

3. 

Definition Workpackage Review 


4. 

Conduct Trade Study 


5. 

Trade Study Documentation 


6. 

Review and Validation 



A list of trade study topics was developed early in the program based on 
emerging design/programmatic drivers that were identified during requirements 
definition (Task 1) efforts. The topics were organized to accommodate a 
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Table 1 . Trade Study Criteria 

System generic 

- Cost 

• Development (nonrecurring) 

• Unit (recurring) 

• Life cycle (training, maintenance, operation) 

- Risk 

• Development (technology readiness) 

• Production (producibility, cost/schcdule) 

- Performance (specific parameters arc trade-study unique) 

l - Standardization/commonality 

• Availability of supported standards 

• Degree of commonality potential 

- Growth/ technology insertion potential 
Onboard hardware generic 

- Physical characteristics (volume, weight, power, thermal) 

- Environment characteristics (radiation tolerance, etc*) 

- Reliability/availability /maintainability 
Unique criteria for individual trades 




logical mapping of option categories into trade study areas. As system 
definition (Task 4) activities progressed, this mapping, the list of trade 
study topics and the associated prioritization of topics were refined to 
reflect evolving architectural needs. Table 2 identifies the current list of 
active trade study topics in priority order. Note that the priority ordering 
does not necessarily reflect criticality but rather the sequence and 
interaction required to support the system definition process. Many of these 
topics have a one-to-one correspondence with Task 2 option categories and the 
corresponding options information base provides the primary source of inputs. 
Other topics represent a mapping of several option categories, some of which 
are required for other trade studies or key design/programmatic decisions. 

Once a prioritized trade study was initiated, a formal problem definition was 
developed and documented in the form of a workpackage. These definition 
workpackages were subjected to Team and NASA review as a mechanism for 
focusing trade study activities. This definition workpackage includes the 
following items: 

1- Reason for Trade Study . Purpose and objectives of the trade study 
with supporting rationale. 

2. Background . Supporting descriptive data that establishes context for 
the study. Includes references to key driving requirements that will 
influence the study. 

3 - Issues • This section identifies major issues that the trade study 
will address and attempt to resolve. 

4 - Applicable Options . Identification of option categories that will be 
a primary source of input parameters for this study. 

5. Trade Study Criteria . Identifies all generic and study-unique trade 
criteria that will be considered in the tradeoff analysis. Criteria 
will include all relevent requirements developed by Task 1. 

Weighting of criteria will be addressed during the trade study. 
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Table 2 

TRADE STUDY STATUS 

GSFC Review NASA Review 

TRAOE 

DEFINITION DEFINITION ANALYSIS PRELIMINARY PRELIMINARY 


TRADE STUDIES 

1 INITIATED 

1 COMPLETE 

INITIATED 

1 PRESENTATION 

1 DOCUMENTATION 

SPACE AUTONOMY 

1 x 

1 

i 

i 

X 

| 11/84 

1 

1 5/85 

FUNCTION AUTOMATION 

i X 

_! 

i 

i 

X 

| 11/84 

f 

! 5/85 (1) 

SOFTWARE TRANSPORTABILITY 

1 x 

_l 

1 8/85 

. 1 

X 

i 

i 

1 8/85 

SYSTEM NETWORK TECHNOLOGY 

1 x 

1 

1 12/84 

J 

X 

I 2/85 

1 

! 5/85 

COMMUNICATIONS STANDARDIZATION 

| X 

1 

| 12/84 

1 

X 

I 2/85 

( 

! 5/85 

ONBOARD LOCAL AREA NETWORKING 

1 X 

_l 

I 11/84 

1 

X 

| 2/85 

1 

I 5/85 

BIU/TRANSMISSION MEDIA 

1 x 

1 

| 11/84 

1 

X 

| 2/85 

1 

1 (3) 

OISTRIBUTEO OPERATING SYSTEM 

1 x 

1 

I 3/85 

J 

X 

i 

i 

j 5/85 (4) 

SOFTWARE DEVELOPMENT 

1 x 

_l 

| 3/85 

1 

X 

i 

i 

| 5/85 

FAULT-TOLERANT COMPUTING 

) X 

1 

| 3/85 

1 

X 

i 

i 

! 5/85 

SPACE QUAL. COMPUTERS 

1 X 

1 

I 3/85 

1 

X 

i 

i 

I 5/85 

OISTR. DATA BASE MANAGEMENT 

! x 

1 

I 3/85 

1 

X 

i 

i 

I 5/85 

SYSTEM INT. , TEST., & VERIF. 

1 X 

1 

| 3/85 

1 

X 

i 

i 

1 8/85 

CREW WORKSTATIONS 

1 x 

1 

I 11/84 

1 

X 

i 

i 

1 5/85 

LANGUAGES - HIGHER ORDER & TEST 

1 x 

_l 

i 

j 


i 

i 

I 5/85 

MASS STORAGE 

1 x 

_l 

1 3/85 

I 

X 

i 

i 

| 5/85 

SPACE COMMUNICATIONS 

1 x 

1 

i 3/85 

1 

X 

i 

i 

! 8/85 

COMMAND AND RESOURCE MANAGEMENT 

1 x 

1 

| 5/85 

1 . 

X 

i 

i 

1 5/85 (5) 


(1) Combined with Space Autonomy - New Title: Space Autonomy and Function Automation 

(3) Incorporated Into Onboard LAN Study 

(4) Two Studies: Software Configuration Management and Software Development Environment Facility 

(5) New Study performed because of Importance to System Definition 
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6. Methodology and Approach . General description of procedure and any 
special tools or techniques employed. 

Once a trade study workpackage had been reviewed and approved, the actual 
conduct of the tradeoff analysis/evaluation was initiated. Trade study 
procedures were generally tailored to specific topics, however, systemmatic 
engineering processes were applied as appropriate. This includes a 
sensitivity analysis to determine the factors that contribute most to the 
relative ranking of top alternatives. Sensitivity analyses provide added 
insight in assessing the study results to determine design and programmatic 
driving factors. They are also used to identify technology items that could 
have significant payoff (performance or cost) but are currently perceived to 
have unacceptable elements of risk. These technology items may be candidates 
for advanced technology development and demonstration. Once preliminary study 
results are available, a trade study report is developed to provide 
preliminary documentation from Team/NASA review and validation. 

SUMMARY 


The preliminary Task 3 (Trade Studies) documentation included in this report 
has been organized into separate trade study reports and packaged as two 
volumes. Only those trade studies that directly influence major SSDS system 
design decisions are included in this report. These are identified in Table 2. 

Table 3 shows a summary of the Sections of this report and the respective 
Trade Studies for each section. It also shows which sections are contained in 
the respective volumes. 
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VOLUME II VOLUME I 


Table 3 


1 

1 

L 

SECTION 

1 

1 TRADE STUDY 

1 


1 

1 

1 

I. 

1 

| SPACE AUTONOMY AND FUNCTION AUTOMATION 


1 

1 

i 

II. 

1 

1 SOFTWARE TRANSPORTABILITY 
| 


1 

1 

III. 

| SYSTEM NETWORK TOPOLOGY 

i 


1 

UJ 

IV. 

1 

| COMMUNICATIONS STANDARDIZATION 


S 1 

3 1 

O I 

V. 

1 ONBOARD LOCAL AREA NETWORKING 
1 


1 

1 

VI. 

| DISTRIBUTED OPERATING SYSTEM 

1 


1 

1 

1 

VII. 

1 

| SOFTWARE CONFIGURATION MANAGEMENT 


I 

1 

L 

VIII. 

! SOFTWARE DEVELOPMENT ENVIRONMENT FACILITY 

1 


1 

1 

1 

IX. 

1 

| SOFTWARE DEVELOPMENT TEST & INTEGRATION CAPABILITY 


1 

1 

X. 

| FAULT TOLERANT COMPUTING 


1 

1 

1 

XI. 

1 

| SPACE QUALIFIED COMPUTERS 

I 


1 

1 

i— * | 

XII. 

1 

| DISTRIBUTED DATA BASE MANAGEMENT SYSTEM 


i— i 1 

UJ I 

21 I 

XIII. 

| SYSTEM INTEGRATION TEST AND VERIFICATION 

i 


ZD 1 

o ! 

> i 

XIV. 

1 

| CREW WORKSTATION 

i 


i 

i 

i 

XV. 

1 

| MASS STORAGE 

l 


i 

i 

i 

XVI. 

1 

| COMMAND AND RESOURCE MANAGEMENT 


i 

i 

L 

XVII. 

| SPACE COMMUNICATIONS 

1 
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I. SPACE AUTONOMY AND FUNCTION AUTOMATION 


1-1 



SPACE AUTONOMY AND FUNCTION AUTOMATION TRADE STUDY 


1.0 INTRODUCTION 

Trade Study Objective . This trade study is performed to identify and 
develop design requirements (characteristics that reflect level of automation) 
for each SSDS function and to allocate the SSDS function in total or in some 
distributed fashion, to space or ground, for both IOC (Initial operational 
Capability) and evolutionary growth of the Space Station program. 

b. Definitions Related to Autonomy/Automation . To facilitate technical 
discussions on the trade study, a set of definitions of terminologies related 
to automation and autonomy are abstracted from various NASA and other 
documents as follows: 

Autonomy : The ability to function as an independent unit or element, over 

an extended period of time, performing a variety of actions necessary to 
achieve pre-des ignated objectives, while responding to stimuli produced by 
integrally-contained sensors . 

A utomation : The ability to carry out a pre-des ignated function or series 

of actions, after being initiated by an external stimulus, without the 
necessity of further human intervention. 

Telepresence : The ability to transfer a human's sensory perceptions 

(e.g., visual, tactile, etc.) to a remote site. 

Teleoperatio n: Remote manipulation in which humans are responsible for 

generating control signals. 

R obot : A generic term, connotating many of the following ideas: A 

mechanism capable of manipulation of objects and/or movement having enough 
internal control, sensing, and computer analysis so as to carry out a more or 
less sophisticated task. The term usually connotes a certain degree of 
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autonomy, and an ability to react appropriately to changing conditions in its 
environment. 

Robotics : The technology by which machines perform all aspects of an 

action, including sensing, analysis, planning, direction/control , and 
effecting/manipulation, with human supervision. 

Space Autonomy : The independence of the onboard subsystems from direct, 
real-time control by the ground (crew or machines) for a specified period of 
time. 

Artificial Intelligence: A discipline which attempts to simulate or 

duplicate the efficient problem — solving capabilities of humans. 

Expert System: A knowledge— based system which stores, processes, and 

utilizes a large data base of information concerning a specific area of 
knowledge to solve problems pertaining to that area. Expert systems are not 
self-adaptive but do provide the ability to generate new concepts and 
relationship about knowledge already in the data base. 

1.1 BACKGROUND 

a. Advanced Technology Advisory Committee Study, The Advanced 
Technology Advisory Committee (ATAC) has provided recommendations on 
automation and robotics options for use by contractors in their Phase B Space 
Station definitions and preliminary designs [1]. The ATAC final report 
published in April 1985, among other things, will assess the impact of the 
various automation concepts for use in Space Station. The assessment study 
performed by Stanford Research, Inc. (SRI) International, determines the 
automation levels which would be technically feasible about 10 years after the 
Initial Operational Capability (IOC) has been established. The ATAC studies 
not only identify the feasible automation levels but also design features 
which are required by IOC to enable the integration of enhanced automation 
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capabilities for future hardware/software upgrades, both onboard and ground. 
These reports are currently being assessed for impact on SSDS System 
definition. 

b. Benefits of Automation and Autonomy. Task 1 developed a function 
list and the corresponding functional performance requirements for SSDS 
functions. Each of these functions will be allocated to onboard and/or 
ground. It is likely that all or nearly all of the allocated functions are 
automated more or less for software implementation. The advantages of SSDS 
function automation can be summarized as follows: 

(1) Lower life Cycle Cost 

o Functional operations are performed by Data Processing (DP) 
hardware/software instead of man. 

o Autonomy minimizes (or eliminates) dependence on communication 
1 inks . 

(2) Increase Productivity 

o Minimize chances for human error 

o Free crew from monotonous, boring, repetitious activities 
o Optimize crew/operator resources in core or payload 
o Improve system performance 

(3) Time Responsivity 

o Meet time critical requirements 

o Improve response times 

(4) Safety 

o Minimize hazardous (human) operations 

c. Methods of Achieving Automation/ Autonomy . Automation is the keynote 
of this study. Automation techniques, which can be applied to achieve 
autonomy, include artificial intelligence (AI), teleoperation, telepresence 
and robotics as defined above. In addition, there are widely applied 
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conventional (or often referred to as algorithmic) automation approaches. By 
definition, a conventional approach is an automation technique whereby a 
machine is programmed to respond to a predefined set of conditions with a 
predefined set of actions. The actions, which may be conditional, can be 
accomplished by use of such programming language as "IF-THEN-ELSE" 
statements. Responses, however, are governed completely by the designer's 
ability to anticipate the situations which the machine will encounter. 
Therefore, conventional (or algorithmic) automation works best for well 
defined situations. Artificial intelligence is known as a branch of computer 
science dedicated to the design and implementation of computer programs that 
make human— like decisions, and can be adaptive and more proficient at making 
decisions. AI systems, such as expert systems, interact with their operators 
in a "natural" way which mimics intelligent behavior. 

A closely related trade study on AI Automation will determine the 
applicability of the advanced AI automation techniques to SSDS functions for 
IOC and evolutionary growth of the Space Station program. 

1.2 ISSUES 

C ost . Figure 1 shows a copy of NASA's Program Planning Guidelines 
that indicate a "cost" constraint to achieve an "opportunity autonomous" Space 
Station. The issue here is to determine the degree of autonomy consistent 
with the cost constraint. For instance, the CDG's (Concept Development Group) 
output report, that specified an autonomy requirement for the total ground 
crew to eventually consist of one person on a Monday through Friday, eight 
hour per day schedule, clearly satisfied NASA's autonomy goal. However, the 
cost to achieve this degree of autonomy at a given onboard productivity level 
was not addressed. 

It is commonly agreed that high cost is expected for automation/autonomy 
software development. Therefore, the allocation of the SSDS functions to 
onboard and the decision on the degree of function automation for an 
operationally autonomous Space Station have to be made consistent with the 
cost constraint. 
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Figure 1. Key Drivers Affecting Allocation/Automation of 
SSDS Function to Onboard/ Ground. 







b. Automation Technology Maturity . — As discussed previously, 
conventional approaches for function automation are well understood and have 
been widely utilized in many systems. Artificial Intelligence and robotics 
techniques show potential for space autonomy applications but are not yet 
mature. A few schedulers have already been developed in the aerospace sector 
by using expert system approaches and several others are currently under 
development. It should be noted that, in general, these expert system 
schedulers are not necessarily reconf igurable to a new application, such as 
those required for the SSDS . Expert systems are the current state— of— art in 
AI technology and are in use in many applications. They are not, however, an 
off-the-shelf item. The availability of tools and methodology to build expert 
systems tailored to the Space Station applications can be expected for the 
IOC. 


c. P rovisions for Growth Past IOC This trade study, will consider not 
only the SSDS function allocation/ automation for IOC; but also for a) 
adding/expanding functions as required, b) migrating functions from ground to 
onboard, and c) increasing the degree of automation past IOC to the year 
2000. To meet the study purpose, two cases have been developed as shown in 
the matrix output provided in section 3.0. The first case is to allow an 
automated payload/core system in space, if the payload/core commands/data are 
originated in flight. The second is that to migrate the diagnostics support 
SSDS function to onboard for growth. 

For growth past IOC, preliminary results show great potential for expert 
systems. As the technology matures, expert system(s) can be used for 
developing short— term schedules. They can also be used for core or customer 
systems status monitoring, and for OTV/OMV checkout and diagnostics. A robot 
may be used in space replacing or supplementing an EVA astronaut to perform 
many tasks, offering improved safety, productivity, and performance capability. 

A separate trade study on AI Automation will discuss in detail the 
applications of advanced automation techniques, such as robotics and expert 
systems, to the SSDS functions for IOC and growth of the Space Station 
Programs . 
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d. Dependence on Communication Link The space—to— ground communication 
link is a finite bandwidth resource that must be shared by many users. The 
demands of the Space Station Program on this link will be very high just to 
transport primary mission data. The link is also subject to outages because 
of the zone-of-exclusion and due to system failures. Therefore, minimizing 
dependence on this link is an important potential benefit of space autonomy. 

1.3 TRADE STUDY CRITERIA 

1.3.1 Generic . These criteria are generic and are applied to all SSDS 
trade studies. 

a. Life Cycle Cost 

o Development and Maintenance cost of hardware and software. 

b. Risk 

o Technical 

o Schedule 

c. Safety 

o Crew safety 

o System failure 

d. Reliability and Availability 

o Hardware 

o Software 

e . Growth 

o Technology insertion 

o Design extendabi 1 ity 
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1.3.2 Trade Study Unique 


As shown in Figure 1, there are seven key drivers used as the trade unique 
criteria for SSDS function allocation/automation. They are criticality, 
impact, co-location, communication link availability, function autonomy, 
response time, and communication link bandwidth. The way they are used for 
allocating the SSDS functions and assessing degree of automation for function 
automation will be discussed in Section 2.0. This section provides their 
definitions as follows. 

a. C riticality . It is defined as a single character code with a fixed 
number to indicate the necessary recovery time for failures involving SSDS: 


Numerical 

Code 


Descripion 


1 

2 

3 

4 

5 

6 
7 


No interruption allowed, redundant 

Recover within 10 seconds, hot backup 

Recover within 10 minutes, cold backup 

Recover within 24 hours, simple repair, LRU (Line 

Replaceable Unit) available 

Recover within 21 days, safe haven used until recovered 
Recover within 90 days, next logistics supply cycle 
No limit on recovery 


It should be noted that the smaller is the numerical value of the indicator, 
the more critical (shorter) is the time required for recovery when SSDS 
failures occur. 


b. Impact . It is defined with a fixed number to indicate consequences of 
failures of the SSDS as follows: 
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Numerical 

Code 


Description 


1 Loss of life 

2 Hazard, damage to Space Station 

3 Damage to Space Station or mission equipment 

4 Mission aborted, loss of key data, or economic penalty 

5 Crew or operator inconvenience 

6 No substantial impact 

It should be noted that the smaller the number, the more severe the 
consequences of the SSDS failures. 

c . Physical Co— location of Function Data Source and Function User 
(crew/ customer) . This criterion is set for implementing software function in 
space or on ground where input data is generated. 

d. Space/Ground Communication Link Availability . In checking the 
availability of the telemetry /telecommand transmission link, the link related 
components, such as blind spot in TDRSS (tracking and data relay satellite 
system) coverage, link MTBF (mean time between failure) and link MTTR (mean 
time to recovery), should be considered for allocating SSDS functions to 
onboard /ground . 

e. F unction Autonomy . The SSDS functions with significant inter— function 
input/output rates should be grouped and allocated as a group for function 
automation. 

f. Re sponse Time . It relates to data transmission delay due to 
space/terrestrial communication links (i.e., the roundtrip TDRSS/DOMSAT delay 
approximately 2 seconds. 

g. Space/Ground Communication Link Bandwidth . During SSDS function 
allocation, considerations should be given to the finite bandwidth of the 
communication link allocated to the Space Station. 
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14 Applicable Options . The following options have been defined in detail and 
are documented in the options development report (Task 2). They are 
applicable to this trade study. 

2.2.2 Autonomy/Automation 

2.2.2. 2 Function Automation Options 

2. 2. 2. 3 Space Station Autonomy (Ground/Space) 

a. Options for Autonomy Options for autonomy, in general, can be 
categorized into three types, viz., space autonomy, ground implementation, and 
space/ground shared implementation. As defined by NASA, space autonomy means 
that the onboard subsystems are independent from direct and real-time control 
by the ground (crew or machine) for a specific period of time. That implies 
an onboard capability to perform essential subsystem functions, many of which 
have traditionally been done on the ground. To do these (subsystem) functions 
onboard with few or no people requires a high degree of automation. This 
degree of space autonomy depends on what level of automation onboard is 
achievable and affordable, as it will be discussed in the next section. 

b- O ptions for Automation - Degree of Automation As an SSDS function is 
allocated to onboard or ground based on the trade unique criteria given above, 
a decision has to be made on whether the allocated function is to be 
automated; if so, to what degree will it be automated? A resolution to this 
question, in general, is that for any onboard-allocated function crew and 
SSDS resources are required. The degree of automation is an expression of the 
mix of crew and SSDS resources. The concept of the degree of function 
automation is delineated as shown in Figure 2. The horizontal line on the 
figure can be interpreted as a scale for measuring the degree of automation 
relative to the required amounts of crew and SSDS resources. The left-most 
point, L, on the scale represents the labor intensive extreme (i.e., the 
maximal crew resource) while the right-most point, R, represents the automated 
extreme where no crew resource is required. The portion of the scale between 
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TASK 1 



M3 


Figure 2. Degree of SSDS Function Automation 



points, S and R, is partitioned into two regions for mapping all the allocated 
SSDS functions, by three curved lines, They are manual, interactive, and 
automated lines as shown in Figure 2, and abbreviated as M, I, and A, 
respectively, to represent the degree of automation for an allocated SSDS 
function . 

The region between points L and S is for any function that requires no SSDS 
resource. The region between S and T represents the M degree of automation 
for which an allocated function requires minimal SSDS resource at point S, and 
requires increasing SSDS resources (with a corresponding decrease in 
crew/operator activities) proceeding towards point T. The phenomena applies 
similarly to an allocated function at an I automation level in the interactive 
automation region between T and R. The automated region at point R, as 
described above for an allocated function designed at an A automation level 
represents the automated extreme with maximum SSDS hardware and software 
requirements for functional implementation. 

c . Function Automation and Responsibility/DP Resource Assignme nt A s 
noted, the SSDS must provide data processing (DP) resources, both hardware and 
software, for implementing the functions allocated to the SSDS. The type and 
extent of the DP resources provided for function implementation depends on the 
designated level and type of automation. Figure 3 depicts the overall 
relationship between responsibilty assignment (onboard/grond crew, machine) 
and data system resource assignments (onboard/ground) for the different 
degrees of function automation. 

2.0 METHODOLOGY 


Figure 4 depicts the systematic procedures set up by this trade study for 
producing the matrix output as shown in Section 3.0. The key elements of this 
procedure are described below. 
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<1. SSDS Function List Task 1 has defined the functions and the 
functional performance requirements for the SSDS. The SSDS functional 
requirements are organized into a hierarchical set of seven top-level 
functions as follows. 

1.0 Manage Customer/Operator Delivered Data 

2.0 Manage Customer/Operator Supplied Data 

3.0 Schedule and Execute Operations 

4.0 Operate Core Systems 

5.0 Manage SSDS Facilities 

6.0 Develop, Simulate, Integrate, and Train 

7.0 Support Space Station Program 

The organization of functions is carried from the top-level down to the third 
and fourth levels to form a complete SSDS function list consistent with the 
SSDS data flows. This complete 4-level SSDS function list will be used to 
develop the function allocation/automation matrix as shown in Figure 4 in 
section 3.0. 

b. SSDS Function Requirements Data Base Task 1 has developed the 
function requirements data base [2], Included in the requirements data base 
for each function on the function list are those functional characteri sties 
and performance requirements , such as criticality for recovery time, impact, 
response time, automation level, allocation location, input/output functional 
interface, and total data bits in terms of time interval and data rate. These 
information data parameters are abstracted and evaluated to formulate the 
matrix output, as described in the following sections. 

c ■ Interface of Trade Unique Criteria and Requirements Data Base As 
delineated in Figure 4, the matrix output consists of three major portions: 
the SSDS function list, the assessment of allocation criteria for each 
function and the resulting decisions for allocation (onboard vs ground) and 
degree of automation, as illustrated in Figure 5. Taking SSDS function 1.1.1, 
"Acquire Real-Time Data" as an example the following will illustrate how to 
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interpret time entries under the seven "Allocation Criteria" columns that were 
derived from the SSDS Function Requirements Data Base: (the seven trade study 

unique criteria were defined in section 1.3.2). 

Cl - Criticality is "2" (recover within 10 seconds) 

C2 - Impact is "5" (crew/operator inconvenience) 

C3 - Co-location is marked with "Y" (where Y is used as a check mark) 

This co-location information is obtained from a program "sort" 
(through the function requirements data base), that shows all the 
functions of 1.1.1, 1.1.2, , 1.1.5 under function 1.1. 

C4 - Communication Link Availability is marked with "Y". 

This information is obtained by observing the following: 

o A program "sort" (an input/output function interface), 
o Function 1.1.1 is output to Function 1.3.2, Data Capture, 

o Function 1.1.1 is allocated to onboard whereas Function 1.3.2 is 

allocated on the ground. 

As a result, the communication link availability is required for 
functional interface (for data transmission from space to ground) 
between these functions, one onboard and one on ground. 

(5) Function Autonomy is marked with "Y" 

(significant interaction with other SSDS functions) 

(6) Response Time is marked with "Y" 

(Data base shows a response time of 2000 Ms) 
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(7) Communication Link Bandwidth is marked with "Y" 

(data base shows data rate is 1330 K bits/second at a one-second time 
interval) 

3 . 0 RESULTS 

Figure 5, SSDS Function Allocation/Automation Criteria and Decisions, is 
the final product of this trade study. It contains the preliminary decisions 
for function allocation to onboard and/or ground, and for the degree of 
function automation for each SSDS function. It also includes the assessment 
of criteria extracted from the requirements data base used to derive these 
decisions . 

The column headings, abbreviations, and markings on Figure 5 under allocation 
criteria and decisions related to each SSDS function, are defined below: 

o The Cl, C2, ..., C7 used on the figure are defined below and correspond to 
the criteria described in section 1.3.2. 

Cl: Criticality 

C2: Impact 

C3 : Physical co— location between function data source and function user 

C4: Space/ground communication link availability 

C5: Function autonomy 

C6: Response Time 

C7 : Space/ground communication bandwidth 

o The numerical code 1, 2, 3, ..., under Cl and C2 represents the level of 
significance (ranking) of the allocated function as defined in section 
1.3.2. 

o The check mark "Y" under the other five trade unique criteria identifies 
the correlation between the allocated function and the associated 
criterion . 
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o 0 and G under "Decisions Allocation": 

0 : Onboard 

G: Ground 

o A, I, and (1 under "Decisions Automation": 

A: Automated (can be any automation technique) 

I: Interactive 

M: Manual 

In case of multiple levels of automation assigned to an allocated 
function, such as "A, I", or "A,I,M," it implies that the allocated 
function (e.g., subfunctions under 5.1.2, Flight Resource Management, 
which is relatively large in terms of functional characteristics and 
performance requirements ) , is usually implemented with part of the 
function at Manual level, part of it at interactive level, and part of it 
at automated level. 

o Any markings, such as 1, 2, .... Y, 0, G, A, I, and M assigned only to a 
higher level function imply that same markings are assigned to all 
subfunctions under it (without repetition). 

4.0 CONCLUSIONS AMD REMAINING ISSUES 


The trade study has developed an output matrix as shown in Figure 5. This 
product, however may be subject to updates under the following foreseeable 
situations . 

a - AT AC Final Report The final report of the Advanced Technology 

Advisory Committee (ATAC) was not available at the time of completion of this 
trade study. The ATAC report includes recommendations for automation related 
to the SSDS and could significantly influence the final results of this trade 
study. Those reports are under evaluation. 
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b. Task 1 SSDS Function List and Requirements Data Base The SSDS 
function list provides the basic framework for the allocation/automation 
matrix output. The allocation of each function to onboard or ground and the 
assessment of degree of automation to each allocated function are determined 
by the function characteristics and its performance requirements . Therefore, 
when SSDS function definition changes, function additions and/or function 
deletions occur, the SSDS function list and the Requirements Data Base will 
change. Consequently, the decisions on function allocation/automation will be 
affected accordingly, and the output matrix will be automatically updated. 

c . Specific Automation Technique for Future Assessment . As noted , when 
an allocated function in the output matrix is assessed with an "A" for 
function automation, it implies that the function is at the automated extreme, 
by using any automation techniques. If later trade studies show that expert 
system (included in AI automation) are cost effective for such functions, then 
the automation assignment "A" will be changed to an "E" to reflect this 
recommendation . 

5.0 REFERENCES 
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J. J. Zapalac, as appendix to Options "White Paper" on 
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Figure 5. SSDS Function Allacation/Autoeation Criteria and Decisions 
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Figure 5. SSDS Function A1 locatian/Autosatian Criteria and Decisions 
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6.3 Frequency Source Manigeeent 
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Health Maintenance 

4.3. 1.1 Crew Physiological Monitoring 

4. 3.1. 2 Medical Diagnoatici Support 

4.3. 1.3 Treatment Support 

4.3. 1.4 Nutrition Analyses 
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4.5.4. 1 Fault Analysis 

4. 5. 4. 2 Fault Correction 

4. 5. 4. 3 Trend Analysis 

4.5.5 Systes Test and Evaluation 

4.5.6 Coeeand Interface Processing 
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Figure 5. 5SDS Function A1 iocation/Autonation Criteria and Decision 



SPACE SHUTTLE TO SPACE STATION SOFTWARE TRANSPORTABILITY TRADE STUDY 


1 . 0 INTRODUCTION 

This trade study provides a rough first-cut estimate of (1) the current size 
of the space shuttle software in the NASA Mission Support Directorate, (2) the 
amount of this software which might be transported, either whole or in part, 
to the Space Station Program and (3) the value of the transportable software. 


1 . 1 BACKGROUND 

The space shuttle software (and systems) environment is depicted in Figure 
1.1.1. There are two Flight Planning "systems" used to develop requirements 
and to support the verification of project software. The production planning 
system provides flight specific data to the control center, the spacecraft 
system and the crew trainers . Through integrated simulations, the control 
center, the trainer and the spacecraft system mutually perform a validation 
function. These five systems are very well coordinated, but they are also 
very independent. Although there is some compatible hardware among the 
systems, there is a minimal amount of common software (in the planning 
systems). Additionally, the software development techniques employed are 
personalized for each system. The division responsible for the software is 
indicated in each box in Figure 1.1.1. 



Figure 1.1.1. Space Shuttle Software Groups 
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Further characteristics of the five systems are provided in Figure 1.1.2. The 
column designated controls illustrates to some degree the personalized 
development techniques used for each system. 

The amount of software in the Directorate is summarized in Figure 1.1.3. Data 
has not been gathered for the data bases and program products which 

support the space shuttle and are the responsibility of the Directorate. 
Program design language (PDL) and prologue comments are excluded from the 
sizing data in the figure; thus, what is provided represents executable code. 
This sizing data was obtained from each project at a level of detail as low as 
100 source lines of code (SLOC) . In some cases, comments were estimated based 
upon a simple count and then deleted at the summary level. The picture 
presented by this data — a lot of software spread throughout the Directorate — 
is correct even if some of the individual sizes are wrong by 10% or even 20%. 
This data does not include the cumulative amount of all software that was 
developed and later deleted or modified through scrubs; rather, it represents 
the size of the software in the Directorate today . In the form presented, the 
software has been summarized in categories which generally represent the 
complexity (or degree of difficulty in the development process) of the 
software. For example, operating system mods and system services are more 
difficult to develop and maintain than are support and utility software. 


Throughout this study, all size and productivity data have been adjusted to 
reflect executable code only. Comparisons of the data presented here with 
other published data should be aware of a possible difference because of this 
convention . 

1.2 ISSUES 

The following issues are addressed in this trade study: 

1.2.1 SOFTWARE COST MODEL 

A model will be developed — based on space shuttle project experience — to 
estimate the development, maintenance and 10 year life cycle cost (LCC) of a 
large software system. The model will be used to extrapolate an upper bound 
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Figure 1.1.2: Space Shuttle Software Characteristics 
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♦Thousands of source lines of code - PDL and prologue comments excluded 




for the cost incurred by not transporting software between the space shuttle 
and space station projects. 

1.2.2 VALUE OF CURRENT SHUTTLE SOFTWARE 

For cost comparisons, a reference value in manyears (MY) of work will be 
established for the current space shuttle software system. 

1.2.3 SIZE OF TRANSPORTABLE CODE 

An estimate will be made of the size - in thousands of source lines of code 
(KSLOC) - of the software developed for the space shuttle which might be 
transported, either whole or in part, to the Space Station Program (SSP). 

1.2.4 VALUE OF TRANSPORTABLE CODE 

The software cost model will be used to estimate the value (again, in manyears 
of work) of the potentially transportable code. 

1.3 TRADE STUDY CRITERIA 

The following criteria are used to evaluate the options for each of the trade 
study issues. 

1.3.1 GENERIC CRITERIA 

Five generic criteria are common to all trade studies: 

1 . 3 . 1 . 1 COST 

DEVELOPMENT (NON-RECURRING): This is the cost to select, transfer, build and 

test the first working system. 

MAINTENANCE (RECURRING): This is the cost to maintain the working system, 

upgrade the software to satisfy evolving requirements , train new programmers 
and provide user assistance. 
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LIFE CYCLE (NON-RECURRING AND RECURRING): This is the sum of the development 

and maintenance costs over a 10 year period. 


1.3. 1.2 RISK 

DEVELOPMENT (LANGUAGE INSERTION, DESIGN DIFFICULTY): There is some 

uncertainty about the ease with which software modules and portions of modules 
coded in many different languages can be embedded into an ADA (or some other 
language) environment. The ADA-to-transported module interface may present 
unique design problems. 

MAINTENANCE (RECONFIGURATION, COST/SCHEDULE, SKILL LEVELS): Multi-language 

systems are always more difficult to maintain than single— language systems. 
Reconfiguration and upgrades to satisfy new requirements are always slower 
(costlier) and incur more risk when a system is coded in more than one 
language. Programmers who must work in several languages are seldom as 
proficient in any of the languages as programmers who use one language 
exclusively. Programmer training is also more expensive. 

1 . 3 . 1 . 3 PERFORMANCE 

SYSTEM SPEED: This is a measure of the speed at which a software system 

performs the task assigned to it. If the interfaces between languages in a 
multi-language system are not clean, then processing speed will suffer. 

SYSTEM SIZE: This is a measure of the core memory consumption of a system. 

Multi-language systems require language interfaces which make them somewhat 
larger than single-language systems. 

1 . 3 . 1 . 4 ST ANDARDIZ ATION/COMMONALITV 

Standard design and programming practices ensure consistent system response. 
Sections of transported code which do not meet Space Station Project standards 
will have to be modified to satisfy the standards. 
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1 . 3 ■ 1 . 5 GROWTH/TECHNOLOGY INSERTION 


All software systems evolve over time as new requirements surface and new 
technology and algorithms become available. In a multi-language system, it 
may prove difficult to insert new technology into modules coded in some of the 
languages . 

1.3.2 TRADE STUDY UNIQUE CRITERIA 


To be a candidate for transfer, a space shuttle software function must 
correspond to a similar Space Station Project function proposed in Section 6.0 
(Onboard SSDS Definition), 7.0 (Ground SSDS Definition) or 8.0 (System 
Development Concepts) of Reference 3. Each transferred function must be 
capable of being embedded in a new host dedicated to space station processing. 

1.4 APPLICABLE OPTION PAPERS 


Several Task 2 option papers are applicable to this trade study. The total 
list is: 


-1.4.1 
-1.4.2 
- 2 . 2.2 
-2 . 2 . 5 . 1 
-2.5.1 
-2.5.2 
-3.1 
-3.2 
-3.5.2 


Advanced Algorithums 

High Order Language 

Autonomy /Automat ion 

Payload/SSDS Interface Options 

Space Communications 

Wide Area Communications 

Standard ization/Commonal ity Options 

System Management 

Software Development 


The prime option paper among these is 2.5.2, Wide Area Networks. The others 
are of lesser interest. 
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1 . 5 ALTERNATIVES 


This trade study assumes that all space shuttle software transported to the 
Space Station Project will be embedded in one or more software systems 
dedicated entirely to space station processing. No other options are 
considered. Under this constraint, three software re— location alternatives 
are available: 

1.5.1 RE-CODE ALL TRANSPORTABLE SOFTWARE 

With this alternative, all transportable software would be re-coded in a 
single (project) language - probably ADA. This alternative would be taken if 
no significant cost advantage could be obtained by transporting software for 
any of the five software systems in Figure 1.1.1. 

1.5.2 RE-CODE SOME TRANSPORTABLE SOFTWARE 


For this option to be chosen, a cost advantage must be available for 
transporting software for at least one (but not all) of the five shuttle 
software systems. The remaining transportable software would be re-coded in 
the project language. 

1.5.3 TRANSPORT ALL TRANSPORTABLE SOFTWARE 

This alternative would be taken if a significant cost advantage could be 
obtained by transporting software for each of the five shuttle software 
systems . 


2.0 METHODOLOGY 


The numbers cited in this study for the amount of transportable code are rough 
engineering estimates. Data for the current sizes of the Control Center, 
Flight planning. Trainer and Spacecraft Software systems is taken from 
Reference 1. Software cost models are taken from Reference 2. The Space 
Station project software environment is assumed to be the one proposed in 
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Sections 6.0 (Onboard SSDS Definition), 7.0 (Ground SSDS Definition) and 8.0 
(System Development Concepts) in Reference 3. 

The following example illustrates the process used for obtaining estimates of 
the transportable SPF simulator software. It is fairly typical of the 
first-cut estimation processes used for all of the software subsystems. 

Initially, two assumptions are made about the space station simulator 
environment : 

1. The current SPF simulator languages (primarily HLAL, PL/1 and 
Fortran) can be maintained in the SSE. 

2- PL/1, Fortran and HLAL generated object code can be embedded within 

the primary SSE language environment (Ada). 

The following multiplication factors are applied to the current SLOG count for 
each SPF simulator function transferred to the SSE: 


Environment Models 1.0 
Hardware Models 0.8 
Control/Initialization Programs 0.7 
Monitor Programs 0.9 
Math Utility Programs 1.0 


The simulator functions assumed to be re-locatable (along with SLOC counts of 
the transported code) are summarized below. Partial lists of SPF modules 
containing re— locatable code are included as some of the functions. 

Control/Initialization (Transported Code: 2361 SLOC) 

- Provide phased execution of the models within the math model task. 

- Math model initialization. 

- Onorbit step-ahead 

- SMDLEORB 
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Math Utilities (Transported Code: 630 SLOC) 

- Matrix utilities. 

- Random number generator. 

Monitor (Transported Code: 3300 SLOC) 

- Log model data. 

- Compute orbital elements for multiple vehicles. 

- SMDLER10 

Equations of Motion (Transported Code: 3430 SLOC) 

- High rate Taylor series predictor/corrector for vehicle state. 

- Low rate precision integrator (Pines' Method). 

- Gravity model (J_ + P rec i s ion). 

- Sun, Moon, gravity gradient torque influences. 

- SMDLEEOM, SMDLEPRE, SMDLEPLE, SMDLEGRA, SMDLEGGT 

Mass Properties (Transported Code: 4122 SLOC) 

- Mass, center of gravity, inertia computation for 
multiple elements. 

- RCS moment arms . 

- RMS/payload effects. 

- SMDLEMS1 , SMDEMS2 

Target State Vectors (Transported Code: 442 SLOC) 

- Provide equations of motion translational states for up to 
five free— flyers . 

- SMDLETGT 

RMS (Transported Code: 8850 SLOC) 

- Provide rigid and flex arm dynamics. 

- SMDLSRMS , SMDLSDRS 

RCS (Transported Code: 2645 SLOC) 

~ Force/moment due to RCS firings. 

- Jet/vehicle impingement interaction. 

- SMDLGRC1 , SMDLGRC2 
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Star Tracker (Transported Code: 1005 SLOC) 

- Shuttle star tracker hardware. 

- Earth occultation/sun effects. 

- SMLDGSTU 


Simulation Macros (Transported Code: 50,000 SLOC) 

Simulation Control (Transported Code: 60,000 SLOC) 

The amount of SPF simulator software estimated at first cut to be 
transportable to the SSE is 136,785 SLOC (see Figure 3.3,1). 

3.0 RESULTS 

3.1 SOFTWARE COST MODEL 

Sections 3.1.1 through 3.2.4 define a model (taken from Reference 2) for 
estimating software development, maintenance and life cycle costs for the 
space shuttle and space station programs . The model is used in Sections 3.2 
and 3.4 to estimate the value of the current space shuttle software system and 
the value of the shuttle software which may be transported to the Space 
Station Program. 

3.1.1 SPACE SHUTTLE PRODUCTIVITY EXPERIENCE 

Data for the productivity experienced on the shuttle project (Figure 3. 1.1.1) 
was gathered from the Directorate Divisions, Branches and contractors and 
normalized for a work month of 20 days. Where possible (SPF, flight software 
and MOC), the data was also adjusted to include all cost elements of the 
project (system analysis, quality assurance, project management, etc.). There 
was a general lack of data for the productivity experienced with the trainer - 
the 120 SLOC/MM composite was estimated by the FSD Office. This data 
inherently represents the cost of developing software in the peculiar 
environment of each system - the state of the requirements, the amount of 
verification, the skills of the work force, etc. 
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Software System 


SLOC/MM 

MOC 

Operating System Mods 

160 


Applications 

190 


Support 

250 

Flight Planning 

Executive 

240 


Applications 

200 


Analysis 

240 

Trainer 

Operating Systems Mods 

120? 


Applications 

120? 


Offline Support 

120? 


Utilities 

120? 

TPC 

Operating System Mods 

? 


Real Time 

198 


Support 

214 

SPF 

Simulation 

169 


Preprocessors 

278 

Flight Software 

HAL 

78 


Assembler 

51 


Figure 3. 1.1.1: Space Shuttle Productivity Experience 


3.1.2 DEVELOPMENT COST MODEL 

The development cost model partitions the software into categories based upon 
complexity, amount of testing employed, status of requirements , etc. Size 
(KSLOC) and productivity (KSLOC/MM) estimates are developed for each category, 
and then the total development cost is obtained by adding the separate costs: 

SIZE SIZE,, 

1 2 

COST = + + . . . 

P ROD UC IT V IT Y , PROD UCTI V ITY. 

1 2 
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The productivities selected for the model are shown in Figure 3. 1.2.1. For 
the control center, MOC and TPC productivities are assumed to be the same (the 
bulk of the software resides in the MOC and the data in the figure is obtained 
from MOC experience). The production planning productivity is decreased to 
account for common support functions which are not included in the shuttle 
productivity experience. The productivities chosen for the trainer reflect a 
comparison of trainer software with spacecraft software with a consideration 
of less definition in requirements . The productivities for the spacecraft 
software are rounded— off values of the shuttle experience. 


3.1.3 MAINTENANCE COST MODEL 

The maintenance cost model (Figure 3. 1.3.1) assumes that software maintenance 
costs represent between 100% and 150% of development costs - equivalent to 
between 50% and 60% of the total 10 year life cycle cost. To determine the 
number of programmers required to maintain the software, an estimate is made 
for the number of source lines of code that one programmer can maintain in 
each software subsystem. These estimates are chosen (based upon shuttle 
experience) to provide a conservative (low) count for the required number of 
programmers to ensure that only valid conclusions are developed from the 
results . 

3.1.4 LIFE CYCLE COST MODEL 

The 10 year life cycle cost (LCC) model simply assumes that the life cycle 
cost is equal to the sum of the development and maintenance costs for each 
software subsystem: 

LIFE CYCLE COST = DEVELOPMENT COST + MAINTENANCE COST 
n n n 

The total life cycle cost for the project is equal to the sum of the separate 
life cycle costs: 

TOTAL LIFE CYCLE COST = LIFE CYCLE COST 

+ LIFE CYCLE C0ST 2 + ... 
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Software System Productivity (SLOC/MM) 
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Figure 3. 1.2.1: Development Model 
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3.2 VALUE OF CURRENT SHUTTLE SOFTWARE 


Using the software cost model developed in Sections 3.1 - 3.1.4, the total 
value of the current space shuttle project software is estimated to be 10,787 

manyears (Figure 3.2.1). The development cost accounts for 4,750 manyears of 
the total. 

3.3 SIZE OF TRANSPORTABLE CODE 

Estimates of the amount of software which can be transported, either whole or 
in part, from the space shuttle to the space station project are given in 
Figure 3.3.1. The granularity of the numbers in the figure is 1 KSLOC; if the 
total amount of transportable code in a software subsystem rounds off to less 
than 1 KSLOC, then it is considered to be too low for comparison and will not 
show up in the figure. 

Additionally, it has been assumed that the onboard flight software (both 
system services and applications) will be re— coded entirely in a new (non-HAL) 
language. None of it is therefore considered to be transportable . 

Finally, no data was collected for the Flight Planning and Trainer systems, 
lhus, the total amount of re— locatable software is probably larger than the 
1,520 KSLOC shown in the figure. 


3.4 VALUE OF TRANSPORTABLE CODE 

Again, using the software cost model developed in Sections 3.1 - 3.1.4, the 10 
year life cycle cost of the transportable Control Center and Spacecraft (SPF) 
code is estimated to be 1,537 manyears (Figure 3.4.1). the relocatable 
Control Center software accounts for 1,337 manyears; the SPF software, for the 
remaining 200 manyears. No figures are currently available for the Flight 
Planning and Trainer systems. The development cost of the transportable 
Control Center and Spacecraft code is estimated to be 643 manyears. 
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Figure 3.2.1: Value of Current Space Shuttle Software 
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Figure 3.3.1: Space Shuttle Transportable Software Size 



Software System 
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Figure 3.4.1: Value of Space Shuttle Transportable Software 



4 . 0 CONCLUSIONS/RECOMMENDATIONS 


4 . 1 CONCLUSIONS 

The space shuttle software environment is composed of the five systems shown 
in Figure 1.1.1. The current aggregate size of the systems is 9,426 KSLOC, 
representing a 10 year life cycle cost of 10,787 MY and a development cost of 
4,750 MY. 

For two of the five systems (specifically, the Control Center and Spacecraft 
systems), the amount of space shuttle software which might be transported to 
the Space Station Project is estimated to be 1,520 KSLOC, representing a 
development cost of 643 MY. No estimates have been made for the transportable 
software in the other three systems. 

The 643 MY figure for the Control Center and Spacecraft systems should not be 
regarded as the amount of effort which would be saved by transporting software 
from these systems. Background language interface and multiple language 
maintenance costs must be subtracted from the figure to obtain the true 
savings. If these costs are estimated to be 20 percent of the development 
cost (equivalent to 129 MY), then 514 MY of effort will be saved by 
transporting code. 

4.2 RECOMMENDATIONS 


The preliminary recommendation is to transport space shuttle software to the 
Space Station Project. The recommendation is based upon first-cut analyses of 
both economic and technical issues (refer to Sections 4.2.1 and 4.2.2) 
associated with the problem. 

4.2.1 ECONOMIC ISSUES 

The following tasks were performed to determine the economic feasibility of 
transporting space shuttle software to the Space Station Project: 
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1 . 


The total amount of space shuttle software in the NASA Mission 
Support Directorate was estimated and divided into logically separate 
groups. This task was initially accomplished in Reference 1 and was 
presented here again. 

2. Based on the space shuttle experience, a model was developed for 
estimating the cost (in manyears of effort) of large manned 
spaceflight software systems. The model was able to differentiate 
between development (short term), maintenance (long term) and life 
cycle (total) costs. This task was accomplished in Reference 2 and 
was also presented here again. 

3. The Space Station Project software environment was predicted. This 
was done in Reference 3 . 

4. With the data from the previous task, the amount of space shuttle 
software which could be transported to the Space Station Project was 
estimated for two of the five software groups defined in Section 1.1 
(the Control Center and Spacecraft software). 

5. Using the software cost model, the value of the transportable 
software was determined for the Control Center and Spacecraft groups. 

6. The size of the interface software required to embed the transported 
software into a background project language was estimated. 

7. Using the software cost model, the cost of the interface software was 
determined . 
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8. The minimum cost advantage (in manyears of effort) required to 
justify transporting space shuttle software was arbitrarily 
established as one manyear - that is, if one manyear of effort could 
be shown to be saved by transporting software, then the decision 
would be made to transport it. 

9. The interface software cost (obtained in step 7) was subtracted from 
the transportable software value (obtained in step 5). The result 
was larger than the minimum required cost advantage (determined in 
step 8), and it was therefore determined to be economically feasible 
to transport the software. 

10. If the result of the subtraction performed in step 9 had been 
uncomfortably close to the minimum required cost advantage (step 8), 
then at least one more iteration would have been preformed on steps 1 
through 9. In particular, an enhancement in knowledge of the 
predicted software environment (step 3) might greatly improve the 
estimate of transportable code made in step 4. 

Each of the tasks listed above was performed on a software group basis (refer 
to Figure 1.1.1). Separate decisions on transportability were made for each 
group . 

4.2.2 TECHNICAL ISSUES 

The following tasks were performed to determine the technical feasibility of 
transporting space shuttle software to the Space Station Project: 

1. The ADA-to-transported module interface was investigated at a 
first-cut level. No major design problems were identified. 

2. System speed and size penalties for transported software were 
assessed (refer to Section 1.3. 1.3). The software transported into 
the shuttle project SPF simulator was used as a yardstick. 
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In addition, the following technical issues should be considered as the Space 
Station Project requirements evolve: 

1. The host computer hardware environment should be investigated. Any 
changes to the transported code (I/O, etc.) driven by the host 
hardware should be factored into the economic feasibility study in 
Section 4.2.1. 

2. An estimate of the new technology likely to be inserted into the 
Space Station Project should be made. Any transported modules coded 
in languages which cannot support the new technology should be 
identified and candidate work-arounds should be proposed and 
evaluated . 
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SYSTEM NETWORK TOPOLOGY TRADE STUDY 


1.0 TRADE STUDY DEFINITION 

1.1 BACKGROUND AND REQUIREMENTS 

The objective of the network topology trade study is to identify the nodes and 
links which will comprise the network. A large number of requirements drive 
this definition. Every function identified in Task 1 of the SSDS study must 
be allocated to a system node. Any communications between functions allocated 
to different nodes must be serviced by system links. In addition, mission 
requirements have been derived from the Langley data base. The key 
requirements provided here are peak data rates, average data rates and 
allowable delays. In cases where allowable delays are zero, links may be 
sized to meet the peaks. Otherwise, links may be sized to meet the averages. 

1.2 ISSUES TO BE ADDRESSED 

This trade study focuses on two issues. The first is the basic network 
configuration. The identification of the nodes, links, and traffic is 
determined. The second issue is the optimum architecture to manage payload 
data. The analysis of the payload data management is divided into a 
preliminary analysis and a detailed analysis. The preliminary analysis is 
described in Section 2 of this trade study report. The detailed cost 
analysis is described in Section 3. Section 4 provides a description of 
other issues involved and provides the recommended topology. 

1 . 3 CRITERIA 

The primary criteria used to compare alternative architectures is cost. For 
the preliminary analysis, a normalized annual cost is derived. For the 
detailed analysis, the cost is divided into fixed costs and recurring costs. 

A number of other criteria were also used to select a topology. As a result 
of the detailed cost analysis, it was determined that the cost differentials 
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between the topologies were significant, but not overwhelming. The other 
criteria, and how they apply to the topology options, are described in 
Section 4. These include growth potential, risk, and overall considerations 
of the entire Space Station system. 

1 . 4 APPLICABLE OPTIONS 


The following options white papers were used to provide information for this 
study : 

Space Communications (2.5.1) 

Wide Area Communications (2.5.2) 

Mass Storage (1.1) 

Standards (3.1) 

1.5 ALTERNATIVE CONFIGURATIONS 

For the preliminary analysis, three topologies were considered (see Section 
2.5). These were : 

1) Centralized Processing at White Sands 

2) Centralized Processing at Goddard 

3) Distributed Processing 

Of these three, the second option was discarded due to extremely high 
communications cost. For the detailed analysis, a new option was considered 
which was a combination of the two. This "hybrid" option, provides for 
distributed processing of high rate data and centralized processing of low 
rate data. The three options studied in detail are described in Section 3.2. 

2.0 PRELIMINARY ANALYSIS 

The objective of the Space Station Network Topology trade study is to 
identify the nodes and links which will comprise the Space Station Network. 
This will be determined by the system traffic requirements , and also some key 
design decisions. Some of these design issues will be analyzed as part of 
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this trade study, while others will be discussed in terms of assumptions 
which are made and the effects of these assumptions. 

Sections 2.1 through 2.3 identify the network elements and the network 
traffic. Section 2.1 describes the network nodes. These correspond to the 
Space Station Program elements which were defined in Task 1 of the SSDS 
study. Section 2.2 delineates all of the traffic which flows through the 
Space Station IMetwork . This is done on a logical node-to-node basis. 

Section 2.3 discusses the characteristics of the links which will be 
available to carry this traffic. 

Assumptions as to which physical links carry which logical traffic for all 
traffic are presented in Section 2.4. This table includes the results which 
specify the payload data path. It is recognized that the transport and 
processing of payload data will be a major topology driver. Options for the 
routing and processing of payload data are presented in Section 2.5. The 
system performance for each option is predicted using a computer simulation. 
The model which has been developed for this purpose is discussed in Section 
2.6. This model also takes into account the effects of 1, 2, or 3 TDRSS 
single access channels. 

Section 2.7 discusses cost assumptions which were used in assessing the 
various options. It is important to note here that the network nodes are 
SSDS elements, while the network links are SSIS services. It is outside of 
the scope of the SSDS study to analyze in detail the implementation of the 
transportation service (DOMSAT vs. Fiber Optics). It is, however, necessary 
to assign some type of cost to the communications service in order to 
perform a meaningful trade (bandwidth vs. buffer). Thus, a simple measure of 
communications cost will be derived and presented. 

Given the simulation results and the cost assumptions system elements, each 
option is costed and the results of the preliminary analysis are described in 
Section 2.8. 
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2.1 Space Station Network Nodes 


The nodes of the Space Station Network coincide with the Space Station 
Program Elements as identified in task 1 report. In the case of elements for 
which the multiplicity is to be determined, a strawman baseline has been 
developed. Brief descriptions of the nodes along with rationale for the 
baseline are provided in this section. 

2.1.1 The Space Station 

The Space Station node services as a communications concentration point for 
multiple payloads, core subsystems, and other identified elements. These 
include the OMV, OTV, free fliers; with options for STS and the COP. The 
Space Station receives data from the payloads and constellation elements, and 
relays the data to the ground, together with core systems data. The Space 
Station routes the commands and data for payloads, core systems, and other 
SSPE 1 s . The Space Station Network must support real time transmission of 
operating data and commands, near real time transmission of quicklook data, 
and delayed transmission of bulk commands and data. Real time operations of 
the payloads require limited two-way data relay, including audio and video 
links . 

2.1.2 Polar Orbiting Platform(s) 

The POP is a polar platform in sun-synchronous orbit which will be used 
primarily for earth and atmospheric observation. POP has no interaction with 
the Space Station on orbit, but will share some ground data handling 
facilities . 

The Space Station Network must support real time transmission of operations 
data and commands for the POP payloads as well as near real time transmission 
of quicklook science data and delayed transmission of stored commands and 
data. Based on the current mission model, it is assumed that there will be 
two POPS at IOC, three at growth. 
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2.1.3 Co-Orbiting Platform(s) 


For the purpose of this study, it is assumed that the COP maintains 
continuous line-of-sight with the space station. It is recognized that this 
may not be true for certain mission scenarios. The use of a COP-SS link will 
be assumed for both COP— ground and ground— COP traffic. The space station 
network must support real time transmission of operations data and commands 
for the COP and COP payloads as well as near real time transmission of 
quicklook science data and delayed transmission of stored commands and data. 

2.1.4 Data Handling Center (DHC) 

The Data Handling Center serves as the space/ground gateway between the TDRSS 
Ground Terminals (WSGT and IMGT) and the ground— to— ground data distribution 
network. It receives and buffers data, and routes virtual channels onto/from 
the ground netowrk, and handles uplink logon and authorization checking. The 
DHC is located at White Sands. 

2.1.5 Space Station Operations Control Center (SSOCC) 

The SSOCC is responsible for ground support of the Space Station Operations 
and Control. The SSOC receives core data and passes it through to the 
Engineering Data Center (EDC) . It is also the origin of SS core commands. 

2.1.6 POP Control Center (POPCC) 

The POP Control Center is responsible for ground support of the platform 
operations and control. It is assumed that there will be one POPCC for each 
POP. 

2.1.7 COP Control Center (COPCC) 

The COP Control Center is responsible for the ground support of the platform 
operations and control. 
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2.1.8 Payload Operations and Control Centers (POCC's) 


The POCC's are responsible for the ground support of payload operations and 
control. This will include interactive real time commanding and quick look 
analysis on science data. The POCC's will coordinate operations with the 
related platform control center. 

2.1.9 Level Zero Processing Facilities (LZPF) 

The LZPF's are responsible for science data processing and short term (seven 
day storage). The LZPF will support quicklook analysis at the POCC's. 

Based on analysis of the Langley Data Base, six candidate locations have been 
defined for LZPF's. These are: 

LZPF 1 - Goddard Space Flight Center (GSFC) 

LZPF 2 - Marshall Space Flight Center (MSFC) 

LZPF 3 — Johnson Space Flight Center (JSC) 

LZPF 4 - Jet Propulsion Laboratory (JPL) 

LZPF 5 - Lewis Research Center (LERC) 

LZPF 6 - Langley Research Center (LARC) 

It should be noted that LZPF's will be used to support Regional Data Centers 
(RDC's). These are SS.IS elements which perform higher level payload data 
processing. 

2.1.10 Engineering Data Center 

The Engineering Data Center provides archival storage of Space Station 
engineering data. This center will support program and customer requests for 
Space Station historical data. 

2.1.11 Customer Facilities 

Commercial customers, as well as some others, will have their own facilities 
for payload operation and control and data reception, archiving, and 
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analysis. A customer facility may be connected directly to the Space Station 
Network, to a Regional Data Center or to a POCC. When tied to the RDC, the 
customer facility can utilize the support services available at the RDC. 

2.1.12 Ground Services Center (GSC) 

The Ground Services Center (GSC) provides communication and common resource 
coordination for the ground system. It serves to coordinate the scheduling of 
the communication and ground facility resources shared among the Space 
Station, COP, and POP operations control centers. The GSC also collects 
status information from these facilities (outages, data quality monitoring, 
etc.) and prepares reports of this information for both customers and the 
OCCs . 

2.2 The Traffic 

The traffic model used for this study is composed of two parts. Section 2.2.1 
describes the mission traffic model, which was derived using the Langley data 
base. Section 2.2.2 describes the other traffic. 

2.2.1 Mission Traffic Analysis 

The mission traffic data base was initiated with a set of 74 missions. 

Twenty of these missions contained incomplete or questional entries. These 
are listed in Figure 2.2-1. 

Additionally, the following changes were incorporated in the data. 

1. The downlink data rate for TDMX2542 was set to 10 Kbps. 

2. The source for SAAX0220 was set to POP2. 

3. The source for SAAX0225 was set to POP2. 

The remaining payloads were analyzed for each of the years described in the 
data base. Figure 2.2—2 illustrates the total of average downlink data rates 
for the active payloads by years. 
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REPORT FOR 


MISSION # 

SOURCE 

SAAX0202 

PP1 

SAAX0215 

PP1 

C0MM1304 

SS 

SAAX0021 

SS 

SAAX0115 

SS 

SAAX0201 

SS 

SAAX0302 

SS 

SAAX0303 

SS 

SAAX0307 

SS 

SAAX0308 

SS 

SAAX0502 

SS 

TDMX2061 

SS 

TDMX2072 

SS 

TDMX2421 

SS 

C0MM1309 

SS 

SAAX0116 

SS 

SAAX0117 

SS 

SAAX0304 

SS 

SAAX0306 

SS 

TDMX2064 

SS 


DOWNLINK FREQ = 0 OR UL 


DOWNLINK 

DOWNLINK 

DATA RATE 

FREQ/DAY 

0.00 

0.00 

10.00 

0.00 

0.00 

0.00 

100.00 

0.00 

0.00 

0.00 

0.00 

0.00 

50.00 

0.00 

30.00 

0.00 

50.00 

0.00 

1.00 

0.00 

56.00 

0.00 

1000.00 

1.00 

0.00 

0.00 

20.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

2.00 

0.00 

1.00 

0.00 

1000.00 

1.00 


RATE = 25000 kbps 


DOWNLINK 

UPLINK 

DUR HRS 

DATA RATE 

0.00 

0.00 

24.00 

0.01 

0.00 

0.00 

24.00 

1.00 

0.00 

0.00 

0.00 

0.00 

0.00 

2.00 

12.00 

30.00 

24.00 

2.00 

0.00 

0.00 

0.00 

56.00 

0.10 

25000.00 

0.00 

0.00 

0.00 

2.00 

0.00 

0.00 

0.00 

0.00 

0.00 

0.00 

24.00 

0.10 

24.00 

0.10 

0.10 

25000.00 


Excluded Missions 
Figure 2.2-1 
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The traffic was further analyzed for the years 1994 and 1997. Figures 2.2-3 
and 2.2—4 show the mission sets as well as the assumed data destination for 
1994 and 1997. Figures 2.2—5 and 2.2—6 provide detailed downlink traffic 
characteri sties for the two years by mission. Figures 2.2-7 and 2.2-8 
provide point-to-point summaries of the average volumes. Figures 2.2-9 and 
2.2—10 show the command uplink summaries, based on the assumption that the 
bulk of the commands originate at the RDC's. Figure 2.2-11 lists all of the 
video requirements . 

2.2.2 Other Data 

Figure 2.2-12 contains a summary of the other space station system traffic. 
The derivation of these numbers is provided here. 

2.2.2. 1 Space Station Core Engineering 

It is assumed that core engineering data is generated at a rate of 256 Kbps 
(2 # Shuttle). All of this data is assumed to go to the SSOCC. This data, 
along with processed ancillary data, must then go to the engineering data 
center. It is assumed that the processed ancillary data (definitive orbit, 
attitude) will add 4 Kbps data to the traffic from the SSOCC to the EDC . 

2. 2. 2. 2 COP Core Engineering 

It is assumed that COP core engineering data is generated at a rate of 64 
Kbps (2* space telescope). COP core engineering data also goes to the EDC. 

2. 2. 2. 3 POP Core Engineering 

It is assumed that POP Core Engineering data is generated at a rate of 64 
Kbps per POP. (2* Space Telescope.) POP Core Engineering data also goes to 
and the EDC. Mote that there are 2 POPS at "IOC", and three at "Growth." 

2. 2. 2. 4 Space Station Command Uplink 

Space Station Commands go from the SSOCC to the Space Station. It is assumed 
that real time commands and stored program commands combine to generate a 4 

Kbps stream. This is consistent with current shuttle command rates. 
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MISSION # 

C0MM1019 

SAAX0208 

SAAX0209 

SAAX0210 

SAAX0216 

SAAX0228 

SAAX0230 

SAAX0238 

SAAX0211 

SAAX0213 

SAAX0214 

SAAX0219 

SAAX0220 

SAAX0229 

SAAX0231 

SAAX0232 

SAAX0234 

SAAX0235 

SAAX0212 

SAAX0005 

C0MM1014 

C0MM1202 

SAAX0009 

SAAX0207 

TDMX2542 

TDMX2441 

C0MM1206 

TDMX2153 

TDMX2311 

C0MM1201 

COMM1203 

C0MM1204 

SAAX0401 

SAAX0404 

TDMX2011 

TDMX2132 


SPACE STATION SOURCE/RDC REPORT 


MISSION NAME 

SOURCE 

RDC 

Stereo Imaging Spectrometer 

PP1 

GSFC 

Mod. Res. Imaging Spectrometer 

PP1 

GSFC 

High Res. Imaging Spect. (HIRIS) 

PP1 

GSFC 

High Res. Multifreq. MW Radiomet. 

PP1 

GSFC 

Earth Radiation Budget Exp-ERBE 

PP1 

GSFC 

Thermal IR Mapping Spectrometer 

PP1 

GSFC 

Fabry Perot Interferometer 

PP1 

GSFC 

NADIR Climate Interfer./Spectrom. 

PP1 

GSFC 

Laser Atmospheric Sounder and Alt. 

PP2 

GSFC 

Altimeter 

PP2 

GSFC 

Scatterometer 

PP2 

GSFC 

Environmental Monitors 

PP2 

GSFC 

Automated Data Col lect./Loc. System 

PP2 

GSFC 

Cryogenic Interfer/Spectrom. 

PP2 

GSFC 

VIS/UV Spectrometer 

PP2 

GSFC 

Microwave Limb Sounder 

PP2 

GSFC 

Interferometer/Spectr. /Upper Atm. 

PP2 

GSFC 

Upper Atm. IR Radiometer 

PP2 

GSFC 

Synthetic Aperature Radar 

PP2 

JPL 

Transition Radiation and Ion. Cal. 

PP2 

MSFC 

Remote Sensing Test, Dev. and Verif. 

SS 

GSFC 

EOS Production Units 

SS 

GSFC 

ASO I/POF 

SS 

GSFC 

Solar-Terrestrial Observatory 

SS 

GSFC 

Tethered Constellation 

SS 

GSFC 

Guided Wave Optics Data Sys. Expt. 

SS 

JPL 

Biological Production Units 

SS 

JSC 

Solar Dynamic Power 

SS 

LEWIS 

Long-Term Cryogenic Fluid Storage 

SS 

LEWIS 

Microgravity and Materials Proc. Fac. 

SS 

MSFC 

ECG Production Units 

SS 

MSFC 

Microgravity and Materials Process Fac. 

SS 

MSFC 

Microgravity and Mat. Proc. Fac. (MMPF) 

SS 

MSFC 

Microgravity and Mat. Proc. Fac. (MMPF) 

SS 

MSFC 

Spacecraft Materials and Coatings 

SS 

MSFC 

Advanced Radiator Concepts 

SS 

MSFC 


Mission Source Destination 1994 
Figure 2.2-3 
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SPACE STATION SOURCE/RDC REPORT 


MISSION # 

MISSION NAME 

SOURCE 

RDC 

SAAX0004 

SIRTF Platform Mission 

COP 

GSFC 

C0MM1019 

Stereo Imaging Spectrometer 

PP1 

GSFC 

SAAX0208 

Mod. Res. Imaging Spectrometer 

PP1 

GSFC 

SAAX0209 

High Res. Imaging Spect. (HIRIS) 

PP1 

GSFC 

SAAX0210 

High Res. Multifreq. MW Radiomet. 

PP1 

GSFC 

SAAX0216 

Earth Radiation Budget Exp-ERBE 

PP1 

GSFC 

SAAX0228 

Thermal IR Mapping Spectrometer 

PP1 

GSFC 

SAAX0230 

Fabry Perot Interferometer 

PP1 

GSFC 

SAAX0238 

NADIR Climate Interfer./Spectrom. 

PP1 

GSFC 

SAAX0211 

Laser Atmospheric Sounder and Alt. 

PP2 

GSFC 

SAAX0213 

Altimeter 

PP2 

GSFC 

SAAX0214 

Scatterometer 

PP2 

GSFC 

SAAX0219 

Environmental Monitors 

PP2 

GSFC 

SAAX0220 

Automated Data Collect./Loc. System 

PP2 

GSFC 

SAAX0225 

Solar-Terres. Polar Platform Exp. 

PP2 

GSFC 

SAAX0229 

Cryogenic Interfer/Spectrom. 

PP2 

GSFC 

SAAX0231 

VIS/UV Spectrometer 

PP2 

GSFC 

SAAX0232 

Microwave Limb Sounder 

PP2 

GSFC 

SAAX0234 

Interferometer/Spectr. /Upper Atm. 

PP2 

GSFC 

SAAX0235 

Upper Atm. IR Radiometer 

PP2 

GSFC 

SAAX0212 

Synthetic Aperature Radar 

PP2 

JPL 

SAAX0005 

Transition Radiation and Ion. Cal. 

PP2 

MSFC 

SAAX0233 

Submillimeter Spectrometer 

PP3 

GSFC 

SAAX0236 

Doppler LIDAR 

PP3 

GSFC 

SAAX0237 

Differential Absorption LIDAR 

PP3 

GSFC 

C0MM1014 

Remote Sensing Test, Dev. and Verif. 

SS 

GSFC 

C0MM1202 

EOS Production Units 

SS 

GSFC 

SAAX0011 

ASO II/POF + SOT 

SS 

GSFC 

TDMX2261 

Sensor Systems Technology 

SS 

GSFC 

COMM1206 

Biological Production Units 

SS 

JSC 

SAAX0227 

Contained Plasma Experiment 

SS 

LANG 

C0MM1201 

Microgravity and Materials Proc. Fac. 

SS 

MSFC 

C0MM1203 

ECG Production Units 

SS 

MSFC 

C0MM1204 

Microgravity and Materials Process Fac. 

SS 

MSFC 

SAAX0401 

Microgravity and Mat. Proc. Fac. (MMPF) 

SS 

MSFC 

SAAX0404 

Microgravity and Mat. Proc. Fac. (MMPF) 

SS 

MSFC 

TDMX2011 

Spacecraft Materials and Coatings 

SS 

MSFC 

C0MM1208 

Crystal Production Units 

SS 

MSFC 


Mission Source Destination 1997 
Figure 2.2-4 
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SPACE STATION POINT-TO-POINT DOWNLINK 


SOURCE - 

RDC 

MISSION # 

DOWNLINK 
DATA RATE 
(kbps) 

DOWNLINK 

FREQ/DAY 

DOWNLINK 
DUR HRS 

DOWNLINK AVG 
RATE 

PP1 

GSFC 

C0MM1019 

200000.00 

16.00 

0.50 

66666.666660 

PP1 

GSFC 

SAAX0208 

3000.00 

7.00 

0.50 

437.499999 

PP1 

GSFC 

SAAX0209 

160000.00 

16.00 

0.25 

26666.666650 

PP1 

GSFC 

SAAX0210 

50.00 

1.00 

24.00 

50.000000 

PP1 

GSFC 

SAAX0216 

0.24 

1.00 

24.00 

0.240000 

PP1 

GSFC 

SAAX0228 

30000.00 

16.00 

0.20 

3999.999999 

PP1 

GSFC 

SAAX0230 

5.00 

16.00 

0.75 

2.500000 

PP1 

GSFC 

SAAX0238 

30.00 

1.00 

24.00 

30.000000 

PP2 

GSFC 

SAAX0211 

40.00 

16.00 

0.75 

20.000000 

PP2 

GSFC 

SAAX0213 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0214 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0219 

2.50 

0.10 

24.00 

0.250000 

PP2 

GSFC 

SAAX0220 

20.00 

1.00 

24.00 

20.000000 

PP2 

GSFC 

SAAX0229 

10.00 

16.00 

0.75 

5.000000 

PP2 

GSFC 

SAAX0231 

2000.00 

1.00 

24.00 

2000.000000 

PP2 

GSFC 

SAAX0232 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0234 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0235 

20.00 

1.00 

24.00 

20.000000 

PP2 

JPL 

SAAX0212 

300000.00 

16.00 

0.10 

19999.999980 

PP2 

MSFC 

SAAX0005 

100.00 

1.00 

24.00 

100.000000 

SS 

GSFC 

C0MM1014 

300000.00 

1.00 

0.20 

2499.999999 

SS 

GSFC 

C0MM1202 

5.00 

1.00 

24.00 

5.000000 

SS 

GSFC 

SAAX0009 

1400.00 

16.00 

1.00 

933.333332 

SS 

GSFC 

SAAX0207 

10000.00 

4.00 

1.50 

2500.000000 

*SS 

GSFC 

TDMX2542 (10) 10000.00 

8.00 

0.50 

1666.666666 

SS 

JPL 

TDMX2441 

20.00 

1.00 

2.00 

1.666666 

SS 

JSC 

C0MM1206 

5.00 

4.00 

1.00 

0.833333 

SS 

LEWIS 

TDMX2153 

10.00 

1.00 

0.10 

0.041666 

SS 

LEWIS 

TDMX2311 

64.00 

1.00 

24.00 

64.000000 

SS 

MSFC 

COMM 1201 

50.00 

4.00 

1.00 

8.333333 

SS 

MSFC 

C0MM1203 

2.00 

1.00 

24.00 

2.000000 

SS 

MSFC 

C0MM1204 

50.00 

4.00 

1.00 

8.333333 

SS 

MSFC 

SAAX0401 

50.00 

1.00 

24.00 

50.000000 

SS 

MSFC 

SAAX0404 

50.00 

1.00 

24.00 

50.000000 

SS 

MSFC 

TDMX2011 

2.00 

1.00 

0.25 

0.020833 

SS 

** TOTAL 

MSFC 

** 

TDMX2132 

4.00 

1017029.74 

1.00 

0.10 

0.016666 

127849.068500 


Downlink Traffic 1994 by Mission 
Figure 2.2-5 
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SPACE STATION POINT-TO-POINT DOWNLINK 


SOURCE 

RDC 

MISSION # 

DOWNLINK 

DOWNLINK 

DOWNLINK 

DOWNLINK AVG 




DATA RATE 

FREQ/DAY 

DUR HRS 

RATE 




(kbps) 



COP 

GSFC 

SAAX0004 

1000.00 

1.00 

24.00 

1000.000000 

PP1 

GSFC 

C0MM1019 

200000.00 

16.00 

0.50 

66666.666660 

PP1 

GSFC 

SAAX0208 

3000.00 

7.00 

0.50 

437.499999 

PP1 

GSFC 

SAAX0209 

160000.00 

16.00 

0.25 

26666.666650 

PP1 

GSFC 

SAAX0210 

50.00 

1.00 

24.00 

50.000000 

PP1 

GSFC 

SAAX0216 

0.24 

1.00 

24.00 

0.240000 

PP1 

GSFC 

SAAX0228 

30000.00 

16.00 

0.20 

3999.999999 

PP1 

GSFC 

SAAX0230 

5.00 

16.00 

0.75 

2.500000 

PP1 

GSFC 

SAAX0238 

30.00 

1.00 

24.00 

30.000000 

PP2 

GSFC 

SAAX0211 

40.00 

16.00 

0.75 

20.000000 

PP2 

GSFC 

SAAX0213 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0214 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0219 

2.50 

0.10 

24.00 

0.250000 

PP2 

GSFC 

SAAX0220 

20.00 

1.00 

24.00 

20.000000 

PP2 

GSFC 

SAAX0225 

2000.00 

4.00 

4.00 

1333.333332 

PP2 

GSFC 

SAAX0229 

10.00 

16.00 

0.75 

5.000000 

PP2 

GSFC 

SAAX0231 

2000.00 

1.00 

24.00 

2000.000000 

PP2 

GSFC 

SAAX0232 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0234 

10.00 

1.00 

24.00 

10.000000 

PP2 

GSFC 

SAAX0235 

20.00 

1.00 

24.00 

20.000000 

PP2 

JPL 

SAAX0212 

300000.00 

16.00 

0.10 

19999.999980 

PP2 

MSFC 

SAAX0005 

100.00 

1.00 

24.00 

100.000000 

PP3 

GSFC 

SAAX0233 

3.00 

1.00 

24.00 

3.000000 

PP3 

GSFC 

SAAX0236 

30.00 

16.00 

0.75 

15.000000 

PP3 

GSFC 

SAAX0237 

10.00 

16.00 

0.75 

5.000000 

SS 

GSFC 

C0MM1014 

300000.00 

1.00 

0.20 

2499.999999 

SS 

GSFC 

C0MM1202 

5.00 

1.00 

24.00 

5.000000 

SS 

GSFC 

SAAX0011 

50000.00 

16.00 

1.00 

33333.333300 

SS 

GSFC 

TDMX2261 

10.00 

1.00 

4.00 

1.666666 

SS 

JSC 

C0MM1206 

5.00 

4.00 

1.00 

0.833333 

SS 

LANG 

SAAX0227 

50000.00 

1.00 

8.00 

16666.666660 

SS 

MSFC 

C0MM1201 

50.00 

4.00 

1.00 

8.333333 

SS 

MSFC 

C0MM1203 

2.00 

1.00 

24.00 

2.000000 

SS 

MSFC 

C0MM1204 

50.00 

4.00 

1.00 

8.333333 

SS 

MSFC 

SAAX0401 

50.00 

1.00 

24.00 

50.000000 

SS 

MSFC 

SAAX0404 

50.00 

1.00 

24.00 

50.000000 

SS 

MSFC 

TDMX2011 

2.00 

1.00 

0.25 

0.020833 

SS 

MSFC 

C0MM1208 

2.00 

1.00 

24.00 

2.000000 

** TOTAL 

** 


1098586.74 



175043.343600 


Downlink Traffic 1997 by Mission 
Figure 2.2-6 
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SPACE STATION POINT-TO-POINT VIDEO 1994 


S/C 

RDC 

MISSION # DOWNLINK 

D/L 

D/L 

UPLINK 

U/L 

U/L 




VID RATE 

VID 

VID 

VID RATE 

VID 

VID 

ss 



(kbps) 

FREQ 

DUR 

(kbps) 

FREQ 

DUR 

GSFC 

C0MM1202 

22000.00 

1.00 

0.50 

0.00 

0.00 

0.00 

ss 

GSFC 

SAAX0207 

2.00 

1.00 

1.00 

0.00 

0.00 

0.00 

ss 

GSFC 

TDMX2542 

12000.00 

8.00 

0.50 

0.00 

0.00 

0.00 

ss 

JSC 

C0MM1206 

22000.00 

2.00 

1.00 

0.00 

0.00 

0.00 

ss 

LEWIS 

TDMX2153 

90.00 

0.00 

0.00 

0.00 

0.00 

0.00 

ss 

MSFC 

C0MM1201 

22000.00 

2.00 

1.00 

22000.00 

0.20 

0.50 

ss 

MSFC 

C0MM1203 

22000.00 

0.10 

0.10 

0.00 

0.00 

0.00 

ss 

MSFC 

C0MM1204 

22000.00 

2.00 

1.00 

22000.00 

0.20 

0.50 

ss 

MSFC 

TDMX2132 

90.00 

0.00 

0.00 

0.00 

0.00 

0.00 
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SPACE STATION POINT-TO-POINT 

VIDEO 

1997 



S/C 

RDC 

MISSION # 

DOWNLINK 

D/L 

D/L 

UPLINK 

U/L 

U/L 




VID RATE 

VID 

VID 

VID RATE 

VID 

VID 




(kbps) 

FREQ 

DUR 

(kbps) 

FREQ 

DUR 

PP2 

GSFC 

SAAX0225 

2.00 

0.00 

0.00 

0.00 

0.00 

0.00 

SS 

GSFC 

C0MM1202 

22000.00 

1.00 

0.50 

0.00 

0.00 

0.00 

SS 

JSC 

C0MM1206 

22000.00 

2.00 

1.00 

0.00 

0.00 

0.00 

SS 

LANG 

SAAX0227 

2.00 

1.00 

8.00 

0.00 

0.00 

0.00 

SS 

MSFC 

C0MM1201 

22000.00 

2.00 

1.00 

22000.00 

0.20 

0.50 

SS 

MSFC 

C0MM1203 

22000.00 

0.10 

0.10 

0.00 

0.00 

0.00 

ss 

MSFC 

C0MM1204 

22000.00 

2.00 

1.00 

22000.00 

0.20 

0.50 

ss 

MSFC 

C0MM1208 

22000.00 

0.10 

0.10 

0.00 

0.00 

0.00 


Payload Video Requirements 
Figure 2.2-11 
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TYPE 

FROM 

TO 

SS CORE 

SS 

ssocc 

SS ANCIL 

SS 

EDC 

COP CORE 

COP 

COPCC 

COP ANCIL 

COP 

EDC 

POP1 CORE 

POP1 

POPCC 

POP1 ANCIL 

POP1 

EDC 

POP2 CORE 

POP2 

POPCC 

POP2 ANCIL 

POP2 

EDC 

SS CMD 

ssocc 

SS 

SS DATA UP 

ssocc 

SS 

COP CMD 

COPCC 

COP 

COP DATA UP 

COPCC 

COP 

POP1 CMD 

POPCC 

POP1 

POP2 CMD 

POPCC 

POP2 

POP1 DATA UP 

POPCC 

POP1 

POP2 DATA UP 

POPCC 

POP2 

CORE HR VIDEO 

SS 

SSOCC 

CORE LR VIDEO 

SS 

SSOCC 

CORE AUDIO 

SS 

SSOCC 

HR VIDEO 

- SSOCC 

SS 

LR VIDEO 

SSOCC 

SS 

AUDIO 

SSOCC 

SS 

SIM UP 

DSIT 

SS 

SIM DOWN 

SS 

DSIT 

ARCHIVE RETR 

EDC 

LZPFs 

SCHEDULE COORD 

CSC 

ALL 


DUTY 


RATE 

CYCLE 

AVG RATE 

256.00 

100.00 

256.00 

260.00 

100.00 

260.00 

64.00 

100.00 

64.00 

64.00 

100 . 00 

64.00 

64.00 

100.00 

64.00 

64.00 

100.00 

64.00 

64.00 

100.00 

64.00 

64.00 

100.00 

64.00 

4.00 

100.00 

4.00 

256.00 

10.00 

25.60 

4.00 

100.00 

4.00 

64.00 

10.00 

6.40 

4.00 

100.00 

4.00 

4.00 

100.00 

4.00 

64.00 

10.00 

6.40 

64.00 

10.00 

6.40 

22000.00 

100 . 00 

22000.00 

1544.00 

100.00 

1544.00 

64.00 

100.00 

64.00 

22000.00 

100.00 

22000.00 

1544.00 

100.00 

1544.00 

64.00 

100.00 

64.00 

5.00 

5.00 

0.25 

1.00 

5.00 

0.01 

4.80 

50.0 

2.40 

4000 . 00 

100.00 

4000 . 00 


Figure 2.2-12. Other Space Station Traffic Data Base 
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2. 2. 2. 5 Space Station Data Uplink 


The data uplink contains text, graphics, and data base loads. Currently, the 
shuttle 216 Kbps command format allows 128 Kbps for text and graphics. It is 
assumed that this traffic category will produce 256 Kbps with a ten percent 
duty cycle. 

2. 2. 2. 6 COP Command Uplink 

COP commands go from the COPCC to the COP. It is assumed that real time 
commands and stored program commands combine to generate a 4 Kbps stream. 

2.2.2. 7 COP Data Uplink 

Due to the fact that the COP is unmanned, it is assumed that the COP data 
uplink will be one-fourth of the Space Station Data Uplink. 

2. 2. 2. 8 POP Uplink Commands 

POP commands go from the POPCC to the (each) POP. It is assumed that real 
time commands and stored program commands combine to generate one 4 Kbps 
stream (per). This is consistent with COP command assumptions. 

2. 2. 2. 9 POP Data Uplink 

The data uplink assumptions for each POP are identical to the data uplink 
assumptions for the COP. 

2.2.2.10 Space Station Core Video Downlink 

It is assumed that there will be one downlink channel dedicated to 22 Mbps 
high resolution video and one dedicated downlink channel for 1,544 Mbps 
resolution video. This traffic goes from the space station to the SSOCC. 

This affects the network topology study because it utilizes TDRSS bandwidth 
which is thus unavailable for other traffic. 
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2.2.2.11 Space Station Core Video Uplink 


It is assumed that all high resolution video uplink will be required for 
recreation, public relations, and training. This traffic is assumed to be 22 
Mbps with a 5% duty cycle. It is also assumed that there will be one 
dedicated 56 Kbps low resolution video channel from the SSOCC and the space 
station. This affects the network topology study because it utilizes TDRSS 
bandwidth which is thus unavailable for other traffic. 

2.2.2.12 Audio Traffic 

It is assumed that there will be two bi-directional dedicated 32 Kbps audio 
channels between the SS and the SSOCC. 

2.2.2.13 Core Archival Retrieval 

It is assumed that each LZPF will generate enough requests for archived core 
ancillary data to require 4.8 Kbps of data with a 50% duty cycle. 

2.2.2.14 Schedule Coordination 

It is assumed that the GSC will require a continuous 4 Kbps stream to and from 
each ground SSPE, and the Space Station. 

2.3 The Links 

The links in the space station network are SSIS services. The objective of 
this study is to identify key performance requirements for these links. 

Section 2.3.1 discusses the assumptions for the space to ground relay 
service. Section 2.3.2 discusses the ground to ground links. 

2.3.1 Space to Ground Links 

It is assumed that the TORS system will be the main space to ground relay 
service. This system provides multiple access S band service, and single 
access service which includes both K-band (KSA) and S-band (SSA). 
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It is assumed that Reed— Solomon encoding will be applied to the single access 
downlinks, and that the effective bandwidth is reduced by 10%. It is also 
assumed that each space node will have access to one S band multiple access 
link. Figure 2.3-1 shows the assumed TDRSS effective available uplink and 
downlink bandwidths. Note that the encoding overhead is symmetric. 

For purposes of this study, it is assumed that the Space Station will act as 
an intermediate node for all COP traffic (if COP is in continual 
line-of-sight) . This decision was made because the low volume of COP traffic 
in the mission set does not warrant the exclusive use of a TDRSS single access 
channel . 


Service 

MA SSA KSA 

Uplink 


Downlink 

Note: Single-access channel includes Reed-Solomon encoding 


Figure 2.3-1. TDRSS Effective Bandwidth 


10 kbps 

270 kbps 

225 Mbps 

50 kbps 

2.7 Mbps 

270 Mbps 
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2.3.2 Ground-to-Ground Links 


For purposes of this study, it is assumed that ground-to-ground links will be 
available between any two points at any rate. 

2.4 Traffic Assignment 

The traffic which was described in Section 2.2 must flow over the physical 
links which were described in Section 2.3. This is done in two steps. 
Assumptions are made for the assignment of the "other" traffic (Section 
2.2.2). Given these assumptions, further analysis is performed for the 
payload downlink traffic. Note that the topology used to support payload 
uplink traffic is driven by command management philosophy, not traffic volume. 

The traffic assignments for the traffic described in Section 2.2.2 are 
provided in Figure 2.4-1. The key in performing this assignment is that the 
end points of the combined physical links are the same as the end points of 
the logical traffic requirement. For example. Space Station core engineering 
data logically must go from the SS to the SSOCC. This is physically 
implemented with two links; SS-DHC, DHC-SSOCC. 


2.5 Topology Options 

For purposes of this study, it is assumed that all payload outputs are in the 
format of CCSDS packets. For the preliminary analysis, only high rate 
payloads are considered. The function of the ground facilities is to 
reconstruct the payload outputs and transport them to the customer; not 
necessarily in that order. 

Figures 2.5-1 through 2.5-4 illustrate the four topology options for payload 
data transportation and processing. The key difference between the options is 
the location of the data set reconstruction, and the imposed communications 
requirements . The key issue here is the definition of data set 
reconstruction. In the mission data base, there is a field named "Duration." 
It is assumed that a data set is the output of the payload for the specified 
period of duration. 
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SS Core 
COP Core 
POP Core 
SS Cmd Up 
SS Data Up 
COP Cmd Up 
COP Data Up 
POP Cmd Up 
POP Data Up 
Archive Retrievals 
High-Rate Video Up 
High-Rate Video Down 
Low-Rate Video Up 
Low-Rate Video Down 
Audio Up 
Audio Down 
SS Payload Data 
SS Payload Eng Down 
SS Payload Cmd Up 
COP Payload Data 
COP Payload Eng Down 
COP Payload Cmd Up 
POP Payload Data 
POP Payload Eng Down 
POP Payload Cmd Up 
Schedule Coord 




Figure 2.4.1. Traffic Link Assignments 


Figure 2.5-5 shows a summary of the processing and communications requirements 
for each option. 


Option 1 provides for reconstruction of all data sets at White Sands. Once 
the data sets are reconstructed, they are then transmitted to their final 
destination . 


Option 2 provides for the relay of all data from White Sands to Goddard Space 
Flight Center, where the data sets are reconstructed and .transmitted to their 
final destination. The advantage of this approach is that similar processing 
and the associated expertise currently reside at Goddard. The disadvantage is 
that there is added communications cost for a WS- GSFC link. Most of the 

increased expense here is the transport of fill data. 
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Option 1 


Option 2 


Option 3 


Processing 


Communications 


All at 
White 
Sands 

All at 
GSFC 

Distributed 
at R DCS 

Data Sets 
WS-RDCS 

All WS-GSFC 
Data Sets 
GSFC-RDCS 

Streams 

WS-RDCS 


Figure 2.5-5. Processing and Communications Implications 

Option 3 provides for the transmission of packets from White Sands to Level 
Zero Processing Facilities (LZPFs) and the reconstruction of data sets at the 
LZPF. The disadvantage of this approach is that the hardware, spares, and 
maintenance are distributed. There is also an increased configuration 
management burden. The advantage is that communications and buffering costs 
are minimized. 

Option 4 presents physical links which have not yet been discussed; Space to 
LZPF. The disadvantage of studying this option is that there is a large 
degree of risk, as well as cost uncertainty. Also, the key cost issues are 
clearly SSIS issues. This option is presented in order to mention that there 
is a finite probability that data set reconstruction will necessarily be at 
the LZPF's in the future. 

The first three topology options have been simulated and costed. Section 2.6 
presents the simulation model and assumptions. Section 2.7 presents the 
assumptions used to derive system cost. Section 2.8 presents the preliminary 
results . 
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2.6 Simulation Description 


Figures 2.6—1 through 2.6—3 illustrate the three models which were used to 
analyze the Space Station Network. These correspond to the three options 
discussed in Section 2.5. Many key assumptions were made in developing the 
simulation. These are not necessarily design decisions, they are assumptions 
required in order to make a working model. It is important to understand what 
these decisions are in order to evaluate their potential impact on the 
simulation results and any trade study conclusions based on these results. 

2.6.1 Data Set Reconstruction 

Traffic is entered into the system as data sets. These sets are broken into 
packets at the symbol labelled "deconstruct." These packets flow through the 
network until they reach the symbol labelled "reconstruct , " then the data set 
flows through the rest of the system. 

2.6.2 On Board Storage 

Due to the high rates which are being buffered, it is assumed that there will 
be optical disks on board. This means that the on board buffer will be 
managed on a priority FIFO basis (tapes would be LIFO). As a result, payloads 
with low delay requirements are given priority over payloads with less 
stringent requirements . 
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Figure 2.6-1. Network Model for Option No. 
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Figure 2.6-2. Network Model for Option No. 
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Figure 2.6-3. Network Model for Option No. 




2.6.3 Ground Links 


The bandwidths of the ground links is not varied in this study. For each 
link, a high bandwidth is chosen which will result in small queues. The 
bandwidths chosen are presented with the results. 

2.6.4 Schedule Considerations 

The good news for the SSDS is that payloads may be scheduled. The bad news i 3 
that many of the high rate payloads perform land observation. Figure 2 . 6-4 

shows the data rates and triggers that were used by the simulation program. 


Rate 


Mission 

From 

To 

(Mbps) 

Trigger 

Comm1014 

SS 

GSFC 

300 

Land, P« 0.05 

Saax0207 

ss 

GSFC 

10 

Poisson 

Comm1019 

POP 1 

GSFC 

200 

Sunlit Land 

Saax0209 

POP 1 

GSFC 

160 

Sunlit Land 

Saax0228 

POP 1 

GSFC 

30 

Land, P * 0.46 

Saax0212 

POP2 

JPL 

300 

Land, P * 0.23 


Figure 2.6-4. Simulation Traffic 


2.6.5 TDRSS Single Access Channel Model 

TDRSS Single Access Channels are modelled as a resource. For this purpose, it 
is assumed that the Space Station has two, POP1 and POP2, and POP2 has 1. The 
method of modelling one, two, or three channels is by having a TDRSS resource 
grabber (a.g.a. zone of non-contact (ZOIMC)) seize these resources with a high 
priority. Thus, to model a single access channel, the simulation is run with 
5-n ZOlMCs. The ZONCs are scheduled so that for each spacecraft, the ZOIMC is 
at least as long as the maximum possible zone of exclusion. 
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2.7 Cost Assumptions 


Each system configuration is assigned an associated cost. This is the 
combined cost for processing, buffering, and communications. Costs are 
measured on a normalized annual cost basis. 

2.7.1 Processing Cost 

According to a report by CSC (Advanced telemetry processing system feasibility 
study), the required systems will be available at a cost of 10.8 million 
dollars with a recurring cost of 465 thousand dollars. If the development 
cost is spread over two years with a zero percent interest rate, the 
normalized annual cost is $1,545 million— per-y ear per system. For topology 
options one and two, there will be one such system per single access channel. 
For option three, these systems, or smaller versions, will be judiciously 
distributed to the RDC's. 

2.7.2 Buffer Costs 

The buffer costs are described in detail in the Mass Storage trade study. The 
following costs are used here: 

On board buffer $10 per megabit 

Ground buffer $.20 per megabit 

2.7.3 Communications Cost 

Communications costs are extremely difficult to predict. Fiber Optic Systems 
appear to be the wave of the future, but costs are not quoted on a service 
basis. Because the communications service is outside of the scope of the 
SSOS, a very simple method has been derived to assign communications cost. 

Based on technology trends (see Wide Area Network options) it is expected 
that communications costs will be around ten dollars per megabit per mile per 
year. Although satellite costs are mileage independent, this approach should 
result in a meaningful measure of cost. 
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Figure 2.7-1 shows the distances between the NASA centers. An example of the 
cost calculation is provided. The distance between GSFC and WS is 1,728 
miles. Thus, the cost of 300 Mbps service is 10 *300* 1728 = $5,104 per year 



GSFC 

MSFC 

JSC 

JPL 

LRC 

LeRC 

GSFC 

0 

711 

1222 

2289 

139 

305 

WS 

1728 

1120 

717 

670 

1751 

1513 


Figure 2.7-1. Miles Between NASA Sites 


2.8 Preliminary Results 

Computer simulations were run for each of the topology options defined in 2.5 
for one, two and three TDRSS single access channels. Appendix F of the S5DS 
task 4 report provides details of the simulation runs. Appendix A of this 
study provides simulation outputs and cost calculations. Figure 3.1-1 
provides a summary of the cost information. 

Based on the results in Figure 3.1-1, Options 1 and 3 seems comparable. The 
communications costs make Option 2 prohibitive. Also, the cost difference 
between 2 or 3 TDRSS single access channels is small. If only one channel is 
used, on board buffering will cost an additional five million dollars per 
year. 
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Figure 3.1-1 


3.0 Detailed Analysis 

The results of the preliminary analysis of this trade study arrived at two 
basic conclusions. The first is that there should be two TDRSS single access 
channels. The second is that level 0 processing should be either centralized 
at White Sands or distributed to level zero processing centers (LZPFs) which 
would be colocated with RDCs . The next step of this trade study is to 
consider these options in greater detail. In addition to these two, a new 
option wa3 considered which is a hybrid of the centralized and distributed 
options. For this "hybrid" option, the proceesing of the high rate payload 
data is distributed to the points of higher processing (RDCs) and the 
processing of the low rate data is centralized at Goddard. The detailed 
analysis of these three new options entails modelling each option in terms of 
cost elements and performing an economic analysis of the fixed and recurring 
costs. The sensitivities of these costs with respect to technology advances 
and requirements will then be analyzed. Section 3.1 provides a detailed 
analysis of the Langley data base mission traffic for the growth scenario 
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(1997), This information is used to size the cost elements. Section 3.2 
describes the models of each of the three options. Section 3.3 describes the 
methodology which was used to assign costs to each of the model elements and 
provides a cost summary. In assigning these costs, it was very important to 
know whether or not the data is being rate smoothed. When rate smoothing is 
applied, data that does not have a strict (0 hour) delay requirement may be 
buffered in order to reduce both bandwidth and processing requirements . On 
the other hand, smoothing precludes quick-look (within seconds) analysis. 

This study analyzed the system costs both with and without rate smoothing. 
Section 3.4 describes the sensitivities of these costs to changes in mass 
storage and communications cost assumptions. Section 4 discusses the non-cost 
issues which were used to pick the Space Station ground network topology, and 
presents this selection. 

3.1 Detailed Traffic Analysis 

Figure 3.1-la presents a data base report which was used to size the cost 
elements for the three options. These reports have two added columns which 
were used in sizing link bandwidths and smoothing requirements . The column 
labeled "required bandwidth" specifies the bandwidth requirement for the given 
payload as derived from the peak rate, average rate, and delay requirement. 

If the delay requirement is zero, then the required bandwidth is equal to the 
peak bandwidth. If the delay requirement is not zero, then it is assumed that 
the data can be smoothed, and therefore the required bandwidth is equal to the 
average bandwidth. The other column which was used to size the system was 
"Observation size". This is used to determine the size of the smoothing 
buffer. This is calculated by multiplying the peak rate by the duration. 
Figures 3.1-2 through 3.1-4 provide a point to point summary of the peak and 
average data rates. Figure 3.1-2 provides this data for all 1997 missions. 
Figures 3.1-3 and 3.1-4 provide this data for high ( 10Mbps) and low rate 
payloads respectively. 
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ORIGINAL PAQ2 > 
OF POOR QUALITY 


SPACE STATION TRAFFIC REPORT FOR YEAR 1997 


FROM 

MISSION 1 

1997 

RATE 

FREQ/DA Y 

DUR (hrs) 

OELAY 

AVG BAND- 

REQ BAND- 

OBSER- 



OPER 

(Mbps) 



(hrs) 

WIDTH 

WIDTH 

VATION 

* TO 6SFC 


DAYS 





(Mbps) 

(Mbps) 

SIZE 

(Gbytes) 

COP 

SAAX0004 

$ 

1.00000 

1.00 

24.00 

24.00 

1.00000 

1.00000 

10.80000 

PP1 

C0MN1019 

365 

200.00000 

15.00 

0.50 

24.00 

62.50000 

62.50000 

45.00000 

PP1 

SAAX0208 

365 

3.00000 

7.00 

0.50 

3.00 

0.43750 

0.43750 

0.67500 

PP1 

SAAX0209 

365 

160.00000 

15.00 

0.25 

3.00 

25.00000 

25.00000 

18.00000 

PPI 

SAAX02I0 

365 

0.05000 

1.00 

24.00 

3.00 

0.05000 

0.05000 

0.54000 

PP1 

SAAX0216 

365 

0.00024 

1.00 

24.00 

3.00 

~ 0.00024 

0.00024 

0.00259 

PPI 

SAAX0228 

365 

30.00000 

15.00 

0.20 

3.00 

3.75000 

3.75000 

2.70000 

PPI 

SAAX0230 

365 

0.00500 

15.00 

0.75 

3.00 

0.00234 

0.00234 

0.00168 

PPI 

SAAX0238 

365 

0.03000 

1.00 

24.00 

3.00 

0.03000 

0.03000 

0.32400 

PP2 

SAAX0211 

365 

0.04000 

15.00 

0.75 

3.00 

0.01875 

0.01875 . 

0.01350 

PP2 

SAAX0213 

365 

0.01000 

1.00 

24.00 

3.00 

0.01000 

0.01000 

0.10800 

PP2 

SAAX0214 

365 

0.01000 

1.00 

24.00 

3.00 

0.01000 

0.01000 

0.10800 

PP2 

SAAX0219 

365 

0.00250 

0.10 

24.00 

0.00 

0.00025 

0.00250 

0.02700 

PP2 

SAAX0220 

36$ 

0.02000 

1.00 

24.00 

3.00 

0.02000 

0.02000 

0.21600 

PP2 

SAAX0225 

365 

2.00000 

4.00 

4.00 

0.00 

1.33000 

2.00000 

3.60000 

PP2 

SAAX0229 

365 

0.01000 

15.00 

0.75 

3.00 

0.00468 

0.00468 

0.00337 

PP2 

SAAX0231 

365 

2.00000 

1.00 

24.00 

3.00 

2.00000 

2.00000 

21.60000 

PP2 

SAAX0232 

365 

0.01000 

1.00 

24.00 

3.00 

0.01000 

0.01000 

0.10800 

PP2 

SAAX0234 

365 

0.01000 

1.00 

24.00 

3.00 

0.01000 

0.01000 

0.10800 

PP2 

SAAX0235 

365 

0.02000 

1.00 

24.00 

3.00 

0.02000 

0.02000 

0.21600 

PP3 

SAAX0233 

365 

0.00300 

1.00 

24.00 

3.00 

0.00300 

0.00300 

0.03240 

PP3 

SAAX0236 

365 

0.03000 

15.00 

0.75 

3.00 

0.01406 

0.01406 

0.01012 

PP3 

SAAX0237 

365 

0.01000 

15.00 

0.75 

3.00 

0.00468 

0.00468 

0.00337 

SS 

C0MMI0I4 

90 

300.00000 

1.00 

0.20 

24.00 

2.50000 

2.50000 

27.00000 

SS 

C0MNI2O2 

365 

0.00500 

1.00 

24.00 

24.00 

0.00500 

0.00500 

0.05400 

SS 

SAXXOOII 

365 

50.00000 

15.00 

1.00 

0.00 

31.25000 

50.00000 

22.50000 

SS 

T0MX2261 

365 

0.01000 

1.00 

4.00 

0.00 

0.00167 

0.01000 

0.01800 

** SUBTOTAL M 











748.27574 

161.10 

350.40 

153.00 

129.98217 

149.41275 

153.76903 

* TO JPL 
PP2 

SAAX02I2 

365 

300.00000 

15.00 

0.10 

6.00 

18.75000 

18.75000 

13.50000 

** SUBTOTAL ** 












300.00000 

15.00 

0.10 

6.00 

18.75000 

18.75000 

13.50000 

* TO JSC 
SS 

COMM I 206 

365 

0.00500 

4.00 

1.00 

24.00 

0.00500 

0.00500 

0.00225 

** SUBTOTAL ** 












0.00500 

4.00 

1.00 

24.00 

0.00500 

0.00500 

0.00225 

Figure 3.1-la. 1997 Data 

Base Listing 








SPACE 

STATION 

TRAFFIC REPORT FOR 

YEAR 1997 






ROM MISSION 1 

1997 

RATE 

FREQ/DAY 

OUR (hrs) 

DELAY 

AVG BAND- 

REQ BAND- 

OBSER- 


OPER 

(Mbps) 



(hrs) 

WIDTH 

WIDTH 

VATION 


DAYS 





(Mbps) 

(Mbps) 

SIZE 

* TO LANG 








(Gbytes) 

SS SAAX0227 

365 

50.00000 

1.00 

8.00 

0.00 

16.67000 

50.00000 

180.00000 

** SUBTOTAL ** 











50.00000 

1.00 

8.00 

0.00 

16.67000 

50.00000 

180.00000 

* TO MSFC 









PP2 SAAX0005 

365 

0.10000 

1.00 

24.00 

24.00 

0.10000 

0.10000 

1.08000 

SS C0MM12O1 

365 

0.05000 

4.00 

1.00 

24.00 

0.00833 

0.00833 

0.02250 

SS C0MM12O3 

180 

0.00200 

1.00 

24.00 

24.00 

0.00200 

0.00200 

0.02160 

SS COHM1204 

365 

0.05000 

4.00 

1.00 

24.00 

0.00833 

0.00833 

0.02250 

SS SAAX0401 

365 

0.05000 

1.00 

24.00 

3.00 

0.05000 

0.05000 

0.54000 

SS SAAX04O4 

365 

0.05000 

i.00 

24.00 

3.00 

0.05000 

0*05000 

0.54000 

SS TDMX2011 

365 

0.00200 

1.00 

0.25 

1.00 

0.00002 

0.00002 

0.00022 

SS COHM1208 

365 

0.00200 

1.00 

24.00 

24.00 

0.00200 

0.00200 

0.02160 

** SUBTOTAL ** 











0.30600 

14.00 

122.25 

127.00 

0.22068 

0.22068 

2.24842 

** TOTAL ** 











1098.58674 

195. 10 

481.75 

310.00 

165.62785 

218.38843 

349.51970 


Figure 3.1-la (Cont'd). 1997 Data Base Listing (Continued) 
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RVERRGE (KBPS) 



CSFC 

MSFC 

jrsc 

JPL 

LmRC 

LmRC 

TOTRL 

ss 


120 

1 



16667 

50545 

COP 

1000 






1000 

POP 1 

91771 

Bi 






POP z 

3439 



18750 



22189 

POP 3 

23 






23 

TOTRL 

129990 

220 

1 

18750 


16667 

165628 


GSFC 

MSFC 

PERK (KBPS) 

JSC JPL LsRC 

LmRC 

TOTRL 

SS 

350015 

206 

5 



50000 

40026 

COP 

1000 






1000 

POP i 

393085 

100 





393185 

POP 2 

4132 



300000 



304132 

POP 3 

43 






43 

TOTRL 

748275 

306 

5 

300000 


50000 

1098586 


Figure 3.1-2. 1997 Missions 
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RVERRGE (KBPS) 


ssrc hsfc jsc jpl urc l«rc totrl 


16667 50417 



POP z 




POP 3 




TOTRL 

740000 



Figure 3.1-3. 1997 High Rate Missions (> 10 MBPS) 


390000 


300000 


I 







50000 10900C 
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3.2 Options Description 


Sections 3.2.1 through 3.2.3 describe the three options which were considered 
in detail. 

3.2.1. Centralized Option 

Figure 3.2-1 illustrates the centralized processing option. The values in the 
boxes are used for sizing and costing the system. These values are derived 
from the Langley data base, as described in Section 3.1. At the front end of 
the ground system is a bulk recorder. This may be used to record all of the 
data which arrives at the ground terminal. The data is then level 0 processed 
at White Sands. This process naturally smoothes out the data, and it is then 
transmitted to the RDCs at the required rate. It should be noted that 
payloads with a zero delay requirement may get their data with zero delay, but 
it will not be level 0 processed. Production data sets may be sent to these 
users after they have been processed, and as such with some delay. 



Figure 3.2-1. Option 1 - Centralized 
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3.2.2. Hybrid Option 


Figures 3.2-2a and 3.2-2b illustrate the hybrid system with and without 
smoothing. The differences between these figures is the peak communications 
bandwidth and the peak level 0 processing requirement. In the case where 
smoothing is assumed, the peaks are assumed to be equal to the averages for 
data with non-zero delay requirements . This will, in turn, be reflected in 
the communications costs and the level 0 hardware costs. 

For the hybrid option, a virtual channel splitter is used to route high rate 
data streams directly to where the RDCs for those streams are located. The 
level 0 processing for these payloads is then performed at collocated level 0 
processing facilities (LZPFs). The channel which contains the multiplexed low 
rate data is routed to Goddard where it is processed and then transmitted to 
the appropriate RDC. Because some of this data has a zero delay requirement, 
and there is no mechanism at White Sands to sort down to the packet level, the 
entire stream must be sent with no delay. For purposes of this analysis, this 
means that the link bandwidth for this stream must be 8.6 Megabits per second. 



Figure 3.2-2a. Option 2 — Hybrid (With Smoothing) 
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Figure 3.2-2b. Option 2 - Hybrid (Without Smoothing) 


3.2.3. Distributed Option 

Figures 3.2-3a and 3.2-3b illustrate the distributed system with and without 
smoothing. For the distributed option, a virtual channel splitter is used to 
route high rate data streams directly to where the RDCs for those streams are 
located. The level 0 processing for these payloads is then performed at 
colocated level 0 processing facilities (LZPFs). The channel which contains 
the multiplexed low rate data is processed down to packets at White Sands and 
the packets are then sent to the low rate LZPFs for processing. 

3.3 Cost Assumptions 

Figure 3.3-1 illustrates the cost breakdown structure that was used to analyze 
the cost differences between the three options. It should be noted that this 
structure includes cost elements which are not within the SSDS. The purpose 
of this exercise is to obtain a consistent measure which may be used to 
understand the overall cost implications of the various options. Any 
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Figure 3.2-3a. Option 3 — Distributed (With Smoothing) 



Figure 3.2-3b. Option 3 — Distributed (Without Smoothing) 
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SSDS Payload Data Processing Cost Elements 


I. 

II. 

III. 

IV. 

V. 

VI. 

VII. 
VIII. 

IX. 

Figure 3.3-1. Cost Breakdown Structure 


Bulk Storage (Fixed) 

Virtual Channel Splitter (Fixed) 

Level O Hardware 

A. ) Processors, Special Purpose Hardware (Fixed) 

B. ) Maintenance 
Level O Software 

A. ) SW Development and Test (Fixed) 

B. ) SW Maintenance 

Level O Working Storage (Fixed) 

Archival Storage 

A. ) System and Drives (Fixed) 

B. ) Media (Recurring) 

Operations (Recurring) 

Communications Bandwidth (Recurring) 
Smoothing Cost 

A. ) Device (Fixed) 

B. ) Media (Recurring) 


statement of source of information in no way implies any intent to use the 
product specified. It simply specifies the method which was used to obtain 
cost estimates. Figures 3.3-2 through 3.3-7 illustrate the costs which were 
derived from the cost analysis for each of the three options with and without 
smoothing. Figure 3.3-8 provides a summary of this information in the form of 
total fixed (development) and recurring costs for each case. Sections 3.3,1 
through 3.3.9 discuss the cost models which were used to arrive at these 
numbers. Each of these sections is divided into subsections which describe 
the rationale used in developing the cost model derived for that particular 1 
element and the application of the model to the systems being analyzed. 

3.3.1 Bulk Recorder (fixed) 

3.3. 1.1 Cost Model Ampex is currently developing tape recorder which is 
capable of capturing 350 Mbps. It is projected that this recorder will cost 
around $250 thousand. 
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Cost Analysis of Option 1 
Centralized at White Sands 
(assuming smoothing) 


FIXED RECURRING 

($M) ($M) 


I. 

Bulk Recorder 

1.0 


II. 

Channel Splitter 

3.0 


III. 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

31.2 

3.7 

IV. 

Level 0 Software 

A) Develop & Test 

B) SW Maintenance 

27.5 

5.5 

V. 

Level 0 Working Storage 

7.4 


VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

1.3 

VII. 

Operations 


1.2 

VIII. 

Comm Bandwidth 


3.6 

IX. 

Smoothing Cost 

A) Device 

B) Media 




120.0 


15.3 


Figure 3.3-2 
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Cost Analysis of Option 2 
Hybrid System 
(assuming smoothing) 


FIXED 

($M) 


I. 

Bulk Recorder 

1.0 

II. 

Channel Splitter 

3.0 

III. 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

38.7 

IV. 

Level 0 Software 

A) Develop & Test 

B) SW Maintenance 

32.5 

V. 

Level 0 Working Storage 

7.4 

VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

VII. 

Operations 


VIII. 

Comm. Bandwidth 


IX . 

Smoothing Cost 

A) Device 

B) Media 

0.5 


133.0 


Figure 3.3-3 


RECURRING 

($M) 


4.6 

6.5 

1.3 

3.6 
3.6 

0.8 

20.4 
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Cost Analysis of Option 3 
Distributed System 
(assuming smoothing) 




FIXED 

($M) 

RECURRING 

($M) 

I. 

Bulk Recorder 

1.0 


II. 

Channel Splitter 

3.0 


Ill . 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

40.3 

4.8 

IV. 

Level 0 Software 

A) Develop & Test 

B) SW Maintenance 

37.5 

7.5 

V. 

Level 0 Working Storage 

7.4 


VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

1.3 

VII. 

Operations 


6.0 

VIII. 

Comm. Bandwidth 


3.6 

IX. 

Smoothing Cost 

A) Device 

B) Media 

0.5 

0.8 



139.6 

24.0 


Figure 3.3-4 


Cost Analysis of Option 1 
Centralized at Mhite Sands 
(assuming no smoothing) 


FIXED 

($M) 


I. 

Bulk Recorder 

1.0 

II. 

Channel Splitter 

3.0 

Ill, 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

31.2 

IV. 

Level 0 Software 

A) Develop & Test 

B) SW Maintenance 

27.5 

V. 

Level 0 Working Storage 

7.4 

VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

VII. 

Operations 


VIII. 

Comm. Bandwidth 


IX. 

Smoothing Cost 

A) Device 

B) Media 



120.0 


Figure 3.3-5 


RECURRING 

($M) 


3.7 

5.5 

1.3 

1.2 

3.6 


15.3 
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Cost Analysis of Option 2 
Hybrid System 
(assuming no smoothing) 


FIXED 

($M) 


I. 

Bulk Recorder 

1.0 

II. 

Channel Splitter 

3.0 

III. 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

53.1 

IV. 

Level 0 Software 

A) Develop & Test 

B) SUI Maintenance 

32.5 

V. 

Level 0 Working Storage 

7.4 

VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

VII. 

Operations 


VIII. 

Comm. Bandwidth 


IX. 

Smoothing Cost 

A) Device 

B) Media 



146.9 


Figure 3.3-6 


RECURRING 

($M) 


6.4 

6.5 

1.3 

3.6 
13.3 


31.1 
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Cost Analysis of Option 3 
Distributed System 
(assuming no smoothing) 


FIXED 

($M) 


I. 

Bulk Recorder 

1.0 

II. 

Channel Splitter 

3.0 

Ill . 

Level 0 Hardware 

A) Processors, special 
purpose hardware 

B) Maintenance 

55.6 

IV. 

Level 0 Software 

A) Develop & Test 

B) SW Maintenance 

37.5 

V. 

Level 0 Working Storage 

7.4 

VI. 

Archival Storage 

A) System and Drives 

B) Media 

49.9 

VII. 

Operations 


VIII. 

Comm. Bandwidth 


IX. 

Smoothing Cost 

A) Device 

B) Media 



153.9 


Figure 3.3-7 


RECURRING 

($M) 


6.7 

7.5 

1.3 

6.0 

13.3 


34.8 
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WITH SMOOTHING 


OPTION 

FIXED 

($M) 

RECURRING 

(M) 

CENTRALIZED 

120. a. 

15.3 

HYBRID 

133.0 

20.9 

DISTRIBUTED .. 

139.6 

....auQ 


WITHOUT SMOOTHING 


OPTION 

FIXED 

($M) 

RECURRING 

($M) 

CENTRALIZED 

120.0 

15.3 

HYBRID 

J96.9 

31.1 

DISTRIBUTED 

153.9 

39.8 


Figure 3.3-8. Results, Cost for Defined System Elements 


3. 3. 1.2 Actual Cost 

For each option, the cost for the bulk recorders is assumed to be one million 
dollars . 

3.3.2 Virtual Channel Splitter (fixed) 

3.3.2. 1 Cost Model 

The functions of the virtual channel splitter are similar in nature to those 
of the Ford TAC. The rates which must be supported, however, are about two 
orders of magnitude higher. It is assumed the development and production 
costs will be about one order of magnitude higher. 

3. 3. 2. 2 Actual Cost 

For each option, the cost for virtual channel splitter is three million 
dollars . 
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3.3.3 Level 0 Hardware 


Sections 3.3.3. 1 and 3. 3. 3. 2 provide the cost model and actual costs for the 
three options with and without smoothing. Within this analysis an effort has 
been made to determine when redundant systems will be necessary to support 
reliability requirements . Redundancy is assumed more often in the case of no 
smoothing, because in this case the LZPF is the first place in the system 
(other than the bulk record) where the data is stored. Sections 3. 3. 3. 3 and 
3. 3. 3. 4 provide the cost model and actual recurring costs for hardware 
maintenance . 

3.3.3. 1 Hardware Cost Model 

The functions of the high rate level 0 hardware are similar in nature to those 
of the advanced telemetry processing sy stem( ATPS) . The actual ATPS studies 
assumed that the downlink would contain 5% TDM data and 95% packet data. The 
SSDS assumptions call for 100% packet data. The architecture of the ATPS 
allows for modular addition of high performance processors (HPPs) to 
accommodate various bit rates. It is estimated by CDC that each HPP is capable 
of handling 80Mbps of packet data. The cost provided for a basic system which 
includes two HPPs is 5.4 million dollars. Each additional HPP can be 
configured for 1.2 million dollars. 

In order to cost low rate level 0 processing, the PACOR system was used as a 
baseline. This system is able to process a peak rate of 1.5 Mbps and the SEL 
hardware costs about $400,000. For the actual PACOR application, level three 
protocols are handled in the software. It is estimated that if this function 
could be offloaded onto a board, the rate could be increased to 4 Mbps. Many 
processor manufacturers offer families of computers which offer a range of 
options in terms of capabilities in this range. The cost for low rate level 0 
processing is thus assumed to be linearly related to the rate ($0.1 per bps) 
subject to a floor of $400,000. 
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3 . 3 . 3 . 2 Actual Hardware cost 


Option one (centralized) with smoothing: 

At White Sands, one system per SA channel is required with the capability 
to handle 300 MBPS. Such a system would require four HPPs. For purposes 
of reliability, redundant systems have been assumed. Thus, the total cost 
for this option is $31.2 million. 

Option one (centralized) without smoothing: 

Same as option one with smoothing 

Option two (hybrid) with smoothing: 

At Goddard, one high rate system is required with the capability to handle 
150 MBPS. For purposes of reliability, redundant systems have been 
assumed . 

At Langley, one high rate system is required with the capability to handle 
50 MBPS. 

At JPL , one high rate system is required with the capability to handle 
18.75 MBPS. 


At Goddard, one low rate system is required with the capability to handle 
8.6 MBPS. 

The total cost for this option is $38.7 million. 

Option two (hybrid) without smoothing: 

At Goddard, two high rate systems are required with the capability to 
handle 300 MBPS. For purposes of reliability, redundant systems have been 
assumed . 
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At Langley, one high rate system is required with the capability to handle 
50 MBPS. 


At JPL, one high rate system is required with the capability to handle 300 
MBPS. For purposes of reliability, redundant systems have been assumed. 

At Goddard, one low rate system is required with the capability to handle 
8.6 MBPS. 


The total cost for this option is $53.1 million. 

Option three (distributed) with smoothing: 

At Goddard, one high rate system is required with the capability to handle 
150 MBPS. For purposes of reliability, redundant systems have been 
assumed . 

At Langley, one high rate system is required with the capability to handle 
50 MBPS. 


At JPL, one high rate system is required with the capability to handle 
18.75 MBPS. 


At MSFC, one low rate system 
At JSC, one low rate system 

At Goddard, one low rate system is required with the capability to handle 
8.3 MBPS. 

The total cost for this option is $40.3 million. 

Option three (distributed) without smoothing: 

At Goddard, two high rate system is required with the capability to handle 
300 MBPS. For purposes of reliability, redundant systems have been 
assumed . 
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At Langley, one high rate system is required with the capability to handle 
50 MBPS. 

At JPL, one high rate system is required with the capability to handle 300 
MBPS. For purposes of reliability, redundant systems have been assumed. 

At Goddard, one low rate system is required with the capability to handle 

8.3 MBPS. 

At MSFC, one low rate system 
At JSC, one low rate system 

The total cost for this option is $55.6 million. 

3. 3. 3. 3 Maintenance Cost Model 

A long-standing rule of thumb is that hardware maintenance costs one percent 
per month of the hardware cost. 

3. 3. 3. 4 Actual Maintenance Cost 

Option one with Smoothing: 

Option one without Smoothing: 

Option two with Smoothing: 

Option two without Smoothing: 

Option three with Smoothing: 

Option three without Smoothing: 

3.3.4 Level 0 Software 

Sections 3. 3. 4.1 and 3. 3. 4. 2 provide the software cost model and actual costs 
for the three options. Sections 3. 4. 3. 3 and 3. 4. 3. 4 provide the cost model 
and actual recurring costs for software maintenance. 


$3.7 Million per year 
$3.7 Million per year 
$4.6 Million per year 
$6.4 Million per year 
$4.8 Million per year 
$6.7 Million per year 
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3.3.4. 1 Software Cost Model 


The total system cost for software is assumed to grow proportionally with the 
number of locations over which the software is distributed. Due to the use of 
standard CCSDS packets, it is expected that a large quantity of software will 
be existing and reusable. Based on these two facts, the following formula has 
been derived to predict the cost of the level zero software: 

level 0 software cost = $25M * ( 1 + 0.1 * (number of locations)) 

3. 3. 4. 2 Software Actual Cost 

Cost For option 1: $27. 5M 

Cost For option 2: $32. 5M 

Cost For option 3: $37. 5M 

3. 3. 4. 3 Software Maintenance Cost Model 

The following formula has been derived to predict the cost of the software 
maintenance cost: 

Maintenance cost = Development cost * .2 

3. 3. 4. 4 Actual Software Maintenance Cost 

Cost For option 1: $5.5M 

Cost For option 2: $6 . 5M 

Cost For option 3: $7.5M 

3.3.5 Level 0 Working Storage (Fixed) 

The cost of both working storage and archival (7 day) storage are very 
sensitive and very high. For this reason, a parametric cost model has been 
constructed for each of these. Given the parametric models, appropriate 
parameters which define the SSDS requirements are plugged in to derive the 
cost . 
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3.3.5. 1 Level 0 Working Storage Cost Model 


It is assumed that the working storage will be supported using fixed magnetic 
disks. The following is an analysis of the cost of magnetic disk based 
systems. The costs will be derived as a function of the data rate entering 
the system and the duration of time which the data must be stored. 

Parameters : 

h - Hours of storage required 
r - average data rate (megabits per second) 

A - "Archive size" (gigabytes) 
cl - cost per disk 
gl - gigabytes per disk 

Calculations 

A(gigabytes) = r (megabits/sec) * h (hours) * 60 (min/hour) * 60 (sec/min) 
* .125 (bytes/bit) * .001 (giga/mega) 

= r * h * 0. 45 

System cost = number of disks * cost per disk 
= (A/gl)*cl 


Cost 

(0.45 * r * h * cl ) / gl 

3. 3. 5. 2 Actual Level 6 Working Storage Cost 

Actual Cost Assumptions (Based on existing RA81 3-pack) 

gl = 1.2 gigabytes 
cl = $40,000 
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Actual Requirements 


r = 165 Mbps 
h = 3 hours 

Therefore, for each option, the cost for level 0 working storage is $7.4 
million. 

3.3.6 Archival (7 day) Storage 

It is assumed that the seven day storage requirement will be supported using 
erasable optical disks. As such, in addition to the fixed development cost 
there is a recurring cost associated with supplying the media. Sections 
3.3.6. 1 and 3. 3. 6, 2 provide the cost model and actual costs for both the 
development and recurring media costs. 

3. 3. 6.1 Archival Storage Cost Model 

The following is an analysis of the cost of optical disk based systems. The 
costs are derived as a function of the data rate entering the system and the 
duration of time which the data must be stored. 

For the analysis of optical systems, it is assumed that the media must be 
replaced. This analysis develops parametric cost models for fixed (3.3.6. 1) 
and recurring (3. 3. 6. 3) cost. 

It is assumed that not all disks will be "on-line". "On-line" disks are 
mounted in drives. Automatic retrieval (ala jukebox) is assumed. A 
percentage of on line storage is assumed based on similar existing systems. 
The cost for on-line gigabytes includes high speed drive, support software, 
and retrieval system. 
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Parameters 


h - Hours of storage required 
r - average data rate (megabits per second) 
A - "Archive size"(gigabytes) 


p - 

proportion of on-line 

storage 

c2 - 

cost per gigabyte on- 

line storage 

c3 - 

media cost per disk 


g2 - 

gigabytes per disk 


W - 

Writes per Disk 



Calculations 

Fixed cost Calculation 

On-line gigabytes =p#r#h*0.45 

fixed cost = on-line gigabytes * cost per on-line gigabyte 
Recurring cost 

Recurring cost = Cost to fill archive # number of times 
per yr media replaced 

Cost to fill = disks required to fill * cost per disk 
= (A/g2)*c2 

= (0.45 * r * h * c3) / g2 

Times media replaced = times archive filled / writes per disk 

Times archive filled = hours per year / hours to fill 

= (365 * 24) / h 

Times media replaced = (365 # 24) / ( h # W) 
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Cost 


Fixed cost =c2#p#r#h#0.45 recurring cost 
= (3942 * r) * ( c3 / ( W * g2 )) 

3. 3. 6. 2 Actual Archival Storage Cost 

Actual Cost Assumptions 

p = 0.2 ( 20 % ) 

c2 = $20,000 / megabyte 
c3 = $400 / disk 
g2 = 2 gigabytes 
W = 100 writes per disk 

Actual Requirements 

r = 165 Mbps 
h = 168 Hours 

Therefore, for each option, the fixed cost for archival is $49.9 Million and 
the recurring cost is $1.3M per year. 

3.3.7 Operations (recurring) 

3.3.7. 1 Operations Cost Model 

It is determined that six full-time(24 hour) positions will be required to 
support the SSDS functions at each LZPF. This translates to twenty-four 
individuals. Assuming that each individual costs fifty thousand dollars per 
year, the formula for the recurring operations cost is : 

Operations Cost = (# OF RDCS) * $1.2M 
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3. 3. 7. 2 Actual Operations Cost 


Cost For option 1 : $1.2M 
Cost For option 2 : $3.6(1 
Cost For option 3 : $6.0(1 

3.3.8 Communications Bandwidth (recurring) 

3.3.8. 1 Communications Bandwidth Cost Model 

It is important to note that this is not an SSDS function, and will not be 
reflected in the SSDS design. It is necessary to consider this element to 
understand cost differences between centralized vs distributed system. It is 
also important to understand the sensitivity of the system cost and system 
design to the cost of the communications. 


In order to measure the communications cost, a variable must be selected which 
represents the state of the art of communications. It is assumed that the 
communications media will be optical fibers, and therefore the cost is 
measured in dollars per Mbps per mile per year. Based on projected fiber 
optics costs, the figure $10/Mbps/mile/yr is used. 


3. 3. 8. 2 Actual Communications Bandwidth Cost Model 


Figures 3.3-9 and 3.3-10 derive the communications cost for each option with 
and without smoothing. The following is a summary of these costs. 


Option one with Smoothing: 
Option one without Smoothing: 
Option two with Smoothing: 
Option two without Smoothing: 
Option three with Smoothing: 
Option three without Smoothing: 


$3.6 Million per year 
$3.6 Million per year 
$3.6 Million per year 
$13.3 Millionper year 
$3.6 Million per year 
$13.3 Million per year 
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Communications 

Cost Analysis 



(assuming 

smoothing) 


Option 1 - Centralized 

at White Sands 



Link 

Mbps 

Miles 

Mbps#Miles 

WS-GSFC 

150.00 

1728 

259200 

WS-JPL 

18.75 

670 

12562 

WS-LARC 

50.00 

1751 

87550 

WS—MSFC 

0.22 

1120 

246 

WS-JSC 

0.00 

7 17 

0 


TOTAL 



359558 

Option 2 - Hybrid 




Link 

Mbps 

Miles 

Mbps*Miles 

WS-GSFC 

150.22 

1728 

259580 

WS-JPL 

18.75 

670 

12562 

WS-LARC 

50.00 

1751 

87550 

GS-MSFC 

0.22 

711 

156 

GS-JSC 

0.00 

1222 

0 

TOTAL 



359848 

Option 3 - Distributed 




Link 

Mbps 

Miles 

Mbps*Miles 

WS-GSFC 

150.00 

1728 

259200 

WS-JPL 

18.75 

6/0 

12562 

WS-LARC 

50.00 

1751 

87550 

WS—MSFC 

0.22 

1120 

246 

WS-JSC 

0.00 

717 

0 

TOTAL 



359558 

Communications Cost 




Option 

Mbps*Miles 

$/Mbps/Mi le/Yr 

$/Yr 

1 

359558 

10 

3.595,580 

2 

359848 

10 

3,598,480 

3 

359558 

10 

3,595,580 


Figure 3.3-9 
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Communications Cost Analysis 
(assuming no smoothing) 


Option 1 - Centralized at White Sands 


Link 

Mbps (avg) 

Miles 

Mbps#Miles 

WS-GSFC 

150.00 

1728 

259200 

WS-JPL 

18.75 

670 

12562 

WS-LARC 

50.00 

1751 

87550 

WS-MSFC 

0.22 

1120 

246 

WS-JSC 

0.00 

717 

0 

TOTAL 



359558 

Option 2 - Hybrid System 



Link 

Mbps (peak) 

Miles 

Mbps*Miles 

WS-GSFC 

600 . 00 

1728 

1036800 

WS-JPL 

300.00 

670 

201000 

WS-LARC 

50.00 

1751 

87550 

GS-MSFC 

0.31 

711 

220 

GS— JSC 

0.01 

1222 

12 

TOTAL 



1325582 

Option 3 - Distributed 




Link 

Mbps (peak) 

Mi les 

Mbps*Miles 

WS-GSFC 

600 . 00 

1728 

1036800 

WS-JPL 

300.00 

670 

201000 

WS-LARC 

50.00 

1751 

87550 

WS-MSFC 

0.31 

1120 

347 

WS-JSC 

0.01 

717 

7 

TOTAL 



1325704 

Communications Cost 




Option 

Mbps*Miles 

$/Mbps/Mile/Yr 

$/Yr 

1 

359558 

10 

3,595,580 

2 

1325582 

10 

13,255,820 

3 

1325704 

10 

13,257,040 


Figure 3 . 3-10 
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3.3.9 Smoothing Cost 


It is important to note that this is not an SSDS function, and will not be 
reflected in the SSDS design. It is necessary to consider this to understand 
cost differences between centralized vs distributed system because centralized 
system performs the smoothing operation implicitly. This cost is only applied 
in the cases where smoothing is assumed. 

3.3.9. 1 Smoothing Cost Model 

It is assumed that the smoothing will be done using erasable optical disks. 

The cost model for this function is the same as the model for the archive. 

Only the parameters differ. 

3. 3. 9. 2 Actual Smoothing Cost 

Actual Requirements 

r = 100 Mbps 
A = 120 Gbytes 

Therefore, for each option, the fixed cost for archival is $0.5 Million and 
the recurring cost is $0.8M per year. 

3.4 Sensitivities 

The major sensitivities in this system are with respect to communications and 
storage costs. 

3.4.1 Communications Sensitivities 

Although a detailed analysis of the ground communications design is outside of 
the scope of the SSDS study, the fact remains that this element will be an 
integral portion of the ground system. Fiber optic communications appears to 
be the wave of the future, however at this point the costs are highly 
uncertain. For purposes of this trade study, the parameter XI 
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($/mbps/mi le/y r) is used to measure the state of the art of communications. 
Current communications costs for the White Sands to Goddard link have been 
calculated to be about $26/mbps/mile/year. Projections from Fibertrak 
indicate that this will go down to $8/mbps/mile/year . 

Figure 3.4-1 illustrates the overall 10 year costs of the three options as a 
function of communications cost assuming that no smoothing is performed. The 

point here is that a centralized system performs smoothing inherently. The 
advantage of this feature is higher for higher communications costs. 


Sensitivity to Communications Cost 
Assuming No Smoothing 



3.4.2 Mass Storage Sensitivities 

The model used to derive a parametric description of optical disk based system 
mass storage costs is provided in section 3. 3. 6.1. The one parameter which 
describes the state of the art of read/write optical disks is : 

(cost per disk) / ((gigabytes per disk) * (writes per disk)) 
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For purposes of this sensitivity analysis, this variable is known as X2. The 
key here is that the only optical disks currently available are write once 
disks. At current prices, X2 = $125/Gbyte/Write . According to the mass 
storage trade study, it is projected that X2 will go down to 
$0. 45/Gbyte/write . Figure 3.4-2 illustrates the profound impact on the 10 
year cost of the system. The actual design of the system will be highly 
dependent on the state of the art of the optical disk technology. At current 
prices, optical disks would not be included in the system design. 

Advances are being made in the optical disk technology. One key issue is in 
the area of media which can be erased and re— written many times. If 
technology advances to the point where disks may be written to thousands of 
times, then the recurring media cost will be neglible. But how much will 
these systems cost? 


Sensitivity to Archive Cost 
Hybrid System (No Smoothing) 



Archive Duration (Hours) 

Figure 3.4-2. Sensitivity to Archive Cost 
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The key point here is that the cost differences as a function of the state of 
the art of optical disk systems are far greater than the cost differences as a 
function of the topology option chosen. This by no means implies that cost is 
an insignificant factor in picking a topology. It simply points out that 
these differences are not overwhelming, and that other factors should be 
considered in order to pick a topology which will serve as the cornerstone for 
the space station ground system end-to-end payload data processing. 

4.0 Issues and Recommendations 

There are a large number of non— cost issues which are used to help determine 
which topology best serves the overall needs of the Space Station ground 
system. Many of these are difficult to relate to cost, and others deal with 
issues whose scope is larger than the SSDS. Sections 4.1 through 4.3 present 
a number of key issues and explain how these effect the choice of topology. 
Based on this information as well as the results of the cost and sensitivity 
analyses, section 4.4 presents the recommended ground topology for the routing 
and processing of payload data. 

4.1 Physical Proximity to Higher Level Processing 

One key issue is the advantage of co-locating Level 0 processing with the high 
rate missions. Upper level processing is unique to the payload. This 
processing will be performed at Regional Data Centers, and by definition will 
be an SSIS function. It is expected that the RDC's will be distributed and, 
therefore, the advantages of co-location will be gained if the Level 0 
processing is distributed likewise. The advantages of co— location, and thus 
of the hybrid or distributed systems are described in sections 4.1.1 through 
4.1.3. 

4.1.1 Ease of Access to Level 0 Data and Re— Transmission 

One advantage of co-location is that it provides ease of access to the Level 0 
storage from the upper level processing. 
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LANDSAT has had the experience that gaps have been introduced not only by the 
Space-Ground communications, but also by the ground- to-ground 
communications. The data is thus shipped from White Sands to GSI-'C where Level 
0 processing is performed to correct for both kinds of problems. High rate 
missions are the least likely to be able to utilize robust transmission 
protocols, such as re-transmission, and thus the most subject to have such 
problems and require re-transmission. Re-transmission over a Local Area 
Network seems less likely to introduce errors . 

4.1.2 Archival and Other Storage Duplication 

Depending on the design of the SSIS, it may be possible to use the Level 0 
storage (7 day) as a source of data for higher level processing. 

At 165 Mb/s average, temporary storage for 7 days will be a significant cost 
analysis. Significant SSIS cost savings could be achieved if this data store 
is shared. 

4.1.3 Sharing of Other Resources 

Depending on the design and implementation of the SSIS (RDC), it may be very 
possible to share a number of resources between SSDS and SSIS. Specific 
resources considered here may be high performance processors, spare parts, 
hardware maintenance personnel, software maintenance personnel, and operations 
personnel . 

4.2 Evolution to ACTS or TDAS Environment 

It is expected that some time in the future, relay satellites will have the 
capability to downlink data directly to distributed earth terminals. This 
would tend to favor a hybrid approach, as direct downlinks could be used to 
the Level 0 sites, saving on communications costs. Once a centralized 
facility is established, it may be programmatically very difficult to migrate 
to a more distributed environment, given the investment involved, and 
especially if the capability is established at White Sands. 
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4.3 Sensitivity to Requirements 


Many of the requirements which drive this study are subject to change. The 
impacts of changes to these study inputs may be very significant. Sections 

4.3.1 through 4.3.4 describe four of these: 


4.3.1 High Rate Payload Downlink Format 

It has been a study assumption that high rate payloads output CCSDS packets. 

If this is not the case, the centralized Level 0 processing may be much more 
complex. In the case of distributed or hybrid option, the high rate payload 
data processor may be designed to match the downlink format. 

4.3.2 The Langley Data Base The data in the Langley Data Base is frequently 
changing, and probably will continue to change through launch. In light of 
this, the hybrid option has some distinct advantages. If a high rate mission 
is added or deleted, the portion of the system which services that payload may 
be added or deleted, with minimal impact to the rest of the system. On the 
other hand, the marginal cost of adding a low rate payload is minimized 
because the resources which service that payload are shared. 

4.3.3 Real Time and Quick look Data 

If it is assumed that high rate mission POCC's need the full bandwidth in real 
time for quicklook data, then one would tend to co-locate the Level 0 
processing and the POCC for that mission, to meet the real time requirements . 
The communications costs would be less a discriminator between the Level 0 
architectures since the communications costs would be borne anyway for the 
POCC's. If this bandwidth is required, then there is no advantage to 
smoothing and a distinct disadvantage for the centralized approach. 
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4.3.4 Level 0 Delivery Requirements 


It is required to deliver the Level 0 data for high rate missions within 24 
hours, as specified in the Langley Data Base, If longer delays are allowed, a 
centralized system may be preferred. In a centralized system, one could save 
bandwidth from the Level 0 site to the upper level site by mailing an optical 
disk . 

4.4 Conclusion 

Based on the costs and the issues described in sections 3 and 4, the hybrid 
system has been chosen for the baseline ground system design. The major 
reasons for this decision are the fact that the cost differences were not 
overwhelming, combined with the fact that the hybrid system demonstrates 
significant advantages in the areas of flexibility with respect to changing 
system requirements , potential overall ground system cost savings, and better 
potential for future technology insertion. 
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APPENDIX A 


Contents 

A-l - A-4 Communications Costs 
A-5 - A- 13 Buffer Costs 
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SPRCE STRTION NETWORK TOPOLOGY 
TRRDE STUDY 
COMMUNICATIONS COST 

OPTION K3 

SA LINKS 


FROM 

TO 

MILES 

RATE 

COSTOO 

ws 

GS 

1728 

75 

1296 



- 



ws 

JPL 

670 

21 

141 


1437 
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SPRCE STRTION NETWORK TOPOLOGY 
TRRDE STUDY 
COMMUNICATIONS COST 
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TO 
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ws 

GS 

1728 
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4032 

GS 
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SPACE STATION NETWORK TOPOLOGY 
TRADE STUDY 
COMMUNICATIONS COST 

OPTION 21 

SA LINKS 2 


FROM 

TO 

MILES 

RATE 

COSTCO 

ws 

GS 

1728 

466 

8064 

GS 

JPL 


21 

481 



- 
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SPACE STATION NETWORK TOPOLOGY 
TRADE STUDY 
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SPACE STATION NETWORK TOPOLOGY 
TRADE STUDY 
BUFFER COST . 


OPTION _J 
SA LINKS 1 


LOCSTH* BfTDBIttialTS) COST KS Oil CGI. 

, . _ai4 


ss 

220 

10 

2200 

POP! 

510 

10 

5100 

POP2 

352 

10 

3520 

GSFC 

494 

.2 

99 






10939 


3-81 


















SPRCE STRTION NETWORK TOPOLOGY 
TRRDE STUDY 
BUFFER COST 


OPTION _1 


SA LINKS 2 


L0CHT1CK 

RFFOSIZ£(QITS) 

CCS! PK SIT 

COST, 

Cm) 

ss 

216 

.10 

2160 

POP1 

82 

10 

820 

POP2 

245 

10 

2450 

GSFC 

578 

.2 

115 






5545 


3-82 














SPRCE STRTION NETWORK TOPOLOGY 
TRADE STUDY 
BUFFER COST 


OPTION _1 


SA LINKS 3 


10CHT1CK 

RJFFERSIZEtCBlTS) 

COST PO? CEIT 

COST. 

.(It) 

SS 

' 176 

10 

1760 

POP! 

64 

10 

640 

POP2 

233 

10 

2330 

GSFC 

587 

.2 

.117 






4847 


3-83 











SPRCE STATION NETWORK TOPOLOGY 
TRADE STUDY 
BUFFER COST 

OPTION 3 

SA LINKS 1 

LOCUTION HJFFBSIZttCBITS) COST PER CBIT COST. 


ss 220 J_g 2200 

POP! 510 TO 5100 

POP2 '352 10 3520 



3-84 












SPACE STATION NETWORK TOPOLOGY 
TRADE STUDY 
BUFFER COST 


OPTION 


L0CRT1CK 


BLFFBSIZOaiTS) COST PER CHIT 


SA LINKS 

COST. 


ss 

' 216 

10 

2160 

POP1 

82 

10 

820- 

POP2 

245 

10 

2450 










5430 


3-85 














SPACE STATION NETWORK TOPOLOGY 
TRADE STUDY 
BUFFER COST 

OPTION 3 

SA LINKS 3 


L0CKn« OJTERSI2ECCBITSI COST P£X CBIT COST, 

cm , 


ss 

176 

10 

1760 

POP1 

64 

10 

mum 

POP2 

233 

10 

2330 









i 

4730 


3-86 














IV. COMMUNICATIONS STANDARDIZATION 
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COMMUNICATIONS STANDARDIZATION TRADE STUDY 


1.0 Trade Study Definition 

1.1 Background 

The SSDS will develop as a combination of ground and space data networks 
connected through a communication link that involves current and future 
satellites, remote-user Ground Stations and onboard stations. Communications 
will be by way of existing and future networks for data distribution, serving 
both Space Station core and user needs. Data paths will involve several 
network media (e.g., RF, wire, and fiber optics) and protocols (e.g., packet 
sizes, data rates, and message headers). The SSDS must incorporate existing 
and emerging communication standards to promote growth and to realize the 
cost-effective benefits of standardization. This trade study will address the 
following specific areas related to communication standards: 

1) CCSDS and IOS/OSI compatibility issues 

2) Use of CCSDS recommendations for packet telemetry and telecommands, 
telemetry/telecommand channel coding, standard format data unit 
(SFDU) utilization, and application of CCSDS standard time code 
formats 

3) Identification/recommendation of standards (developed or emerging) 
for layers 2—7 of ISO/OSI for both space and ground 


PRECEDING PAGE BLANK NOT FILMED 


4-3 



1.2 Issues 


The following issues are applicable to this trade study: 

1. Use of international and national standards including those from the 

following organizations: International Standards Organization, 

Consultive Committee for Space Data Systems, American National 
Standard Institute (ANSI), Consultive Committee For International 
Telegraph and Telephone (CCITT), European Computer Manufacters 
Association (ECMA) , National Bureau of Standards, EIA .... 

2. Use of commercial non— ISO/OSI standards (proprietary protocols) 

3. Identifying the need for new standards development 

4. Ground and space commonality/migration issues. 

1.3 Selected Criteria 

The selection criteria are as follows: 

o Requirements tradeoffs — the degree to which the option meets the 
requirements of Task 1 and those derived requirements described in 
the Standardization Options paper 

o Technical feasibility — any inherent technological limitations, 
e.g., packet switching speeds 

o Impacts on SSDS elements — examining and balancing the impacts on 
major SSDS elements. These are: 
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Payload Interface 


On-board LAN & DMS 

- Gateways 

TDRS Uplink/Downlink 

- Data Handling Center 

Regional Data Center 

The options paper summarized a number of requirements from the Task 1 report, 
and also from other sources and requirements and implications resulting from 
the Task 1 requirements . These were presented in the options paper according 
to the ISO/OSI layers. These are summarized in the following section. 

1.4 Requirements Affecting Selection of Standards 

The SSIS/SCS (per Figure 1—2 includes both SSDS and non— SSDS elements) shall 
obtain and/or develop standards for customer interfaces in areas such as 
software, critical/limited payload, health and safety monitoring, man-machine 
interfaces, command generation, time code, attitude and position data, 
pointing coordinate systems, data base management systems, graphics displays, 
data handling/archiving/distribution, documentation, configuration control, 
cost accounting, data system requirements definition, operations audit trail, 
etc. When new customer standards are proposed, the SSIS/SCS shall present 
these standards to a customer panel which will provide an impact statement on 
behalf of all customers (Task 1, Section 5. 3. 8. 9). 

The SSDS shall provide standardized language, protocol, format, and 
transmission rates for all SSDS and all SSDS subsystems (Task 1, 5. 3. 8. 9). 
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A3 a first preference, customer interface standards shall be defined in 
accordance with the International Standards Organization (ISO) seven layer 
model for Open Systems Interconnect (OSI) (Task 1, Section 5. 3. 8. 9). 

The SSDS shall use, for each of the seven layers, existing internationally 
accepted standards as a first priority followed by new standards development 
(within the OSI model framework) (Task 1, Section 5. 3, 8. 9). 

The customer interfaces defined within the OSI model shall conform to 
standards defined and controlled by such sources as: 

MBS, National Bureau of Standards 

ANSI, American National Standards Institute 

ECMA, European Computer Manufacturing Association 

CCITT, Consultative Committee for International Telegraph and Telephone 

EIA, Electronic Industry Association 

CCSDS, Consultive Committee for Space Data Systems 

IEEE, Institute of Electrical & Electronic Engineers 

When practical, appropriate standards from these sources shall be used at 
higher layers of the OSI model (Task 1, Section 5. 3. 8. 9). 

For customer interfaces, support commercially available standards. 

Provide ancilliary avionics and housekeeping data (timing, state vector, RF 
communication, system status, acquisition of signal/loss of signal, moding, 
pointing, etc) to the attached payloads and customers (Task 1, Section 
5 . 3 . 2 . 4 ). 
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The SSIS/SCS network data handling shall be independent of the format or 
content of the customer data (CRSS, 3.1.4). 

Customer data shall be delivered without alteration of its contents. Any 
artifacts imposed by the data transport service, e.g., data reversal due to 
communicators buffering, shall be removed before data delivery to the customer 
(CRSS, 5.4.3). 

Format data in self identifying data units (derived). 

Support multiple payloads in a way which minimizes interactions and a minimum 
of software re-conf iguration (Derived). 

Support an evolutionary expansion of the SS DMS (Derived). 

Support the end-to-end BER requirements (10**-6 to 10#*-9). 

Support quality of transport service (computer quality vs normal quality) 
(Derived) . 

Provide real-time distribution of real-time and near real-time data, including 
Level 0 processing, demultiplexing, buffering, routing, and re-transmission 
(Task 1, Section 5. 3. 1.3). 

Provide real-time, raw payload data to the customer (Section 5.3. 1.1). 

Support real-time re-al location of data distribution resources to help meet 
customer priorities (Section 5. 3. 3. 3). 

Support rapid separation of the downlink/uplink by customer ID (Derived). 
Support electronic transmission of data to customers and RDC's (Derived). 
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Support delivery service (immediate delivery vs store & forward delivery) 
(Derived) . 

Support reliability services (verified delivery vs unverified delivery) 
(Derived) . 

Support symmetric services (uplink/downlink) (Derived). 

Allow or support encryption (Derived). 

1.5 Applicable Options 

In the description of communications standards options, four options were 
presented for implementation of an end-to-end standards architecture : 

I) ISO Compatible Standards For Local & Wide Area Networks (space & 
ground) combined with: 

a) CCSDS Packets Implemented As An ISO Upper Layer Standard 

b) CCSDS Packets & Frames Implemented "Below" Onboard ISO 

c) CCSDS Implemented As Alternate Downlink Standards For ISO Layer 
1-3 

II) ISO Standards Only 

Upon subsequent reviews, a consensus developed that the most promising design 
appeared to be the first (la). The options paper presented a number of 
options within each ISO/OSI layer for choices of standards. 
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2.0 Trade Study Methodology & Approach 


This trade study will: 

o compare the design with its major alternate implementation options 

o examine tradeoffs between implementations of the design 

o examine the characteristics of the local and wide area standards that 

should be used 

As noted, there were four major options presented for an end-to-end standards 
architecture. This tradeoff will provide a high level comparison of the 
options. There are several issues within the proposed design option which 
will be discussed. While this study was not intended to select specific 
standards for the LAN and WAN, this trade will characterize the desired 
choices. The choice of standards is driven by the end-to-end topology and the 
needs of each subnetwork, rather than the inverse. 

2.1 Implementation Options 

The following provides an overview of the proposed implementation of an 
end-to-end standards architecture that is consistent with option la identified 
in section 1.5. 

The CCSDS Packet Standard is implemented as application layer data. Each 
packet is delivered to the Space Station local area network. The On-board LAN 
implements some portion of ISO layers 1-7. All headers are added and removed 
by the on— board LAN. The layer 4—7 ISO protocols thus apply from one on— board 
instrument to another. At the downlink gateway, the CCSDS Telemetry packets 
are reassembled into the original source packets. These are framed and 
encoded. Framing is done asynchronously to the packetization, i.e., the 
boundaries do not line up. 
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An inverse process occurs on the ground. The codeblocks are de-coded, and 
frames are removed. The f raming/de-framing process synch's on the frame synch 
code. Packetization and packet recovery is performed using the frame pointer 
to the first packet header, using the packet size data in the packet header 
to recover the original packet (which may be spread through several frames). 
The source packets are then transmitted over the ground wide area network. 

The above is a version of the first option for implementation of an end-to-end 
standards architecture . This proposed design will be compared with two of the 
three other options presented in the options paper. The fourth option in the 
options paper was to only utilize ISO standards. This option was presented 
for logical completeness. Existing ISO standards are not suited to the needs 
of the space-ground link, as noted in the options paper, and thus this option 
implies development of entirely new standards, not a modification of existing 
standards. Since this is at best speculative, this fourth option will not be 
discussed further in this section. 

2.1.1 Requirements Tradeoffs 

SSDS requirements affecting the selection of communications standards has been 
summarized in the options paper. The options will be compared with respect to 
how well key requirements are met. 

In their original form, none of the options support the following services as 
customer selectable options: 

o quality of transport service (computer quality vs normal quality) 
o delivery service (immediate delivery vs store & forward delivery) 
o support reliability services (verified vs unverified delivery) 
o support symmetric services for uplink/downlink 
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This does not provide a discriminator between the options. 


Using a strict interpretation of the requirements, the proposed design does 
not meet the following requirements : 

o The SSIS/SCS data handling shall be independent of the format or 
content of the customer data (CRSS) 

o The data network shall be able to transport and deliver data sets 
intact, without having any knowledge of their internal format or 
content (CRSS, 2. 2. 3. 4) 

These requirements are not met since the CCSDS formats are implemented as part 
of the application data. This is interpreted to mean just that - the headers 
literally treated as data and not examined by the data system. This may not 
be the case if the format were implemented as a standard at some other level. 
Whether it makes any practical difference to implement the formats as 
application, presentation, or transport standards will be discussed in the 
next section. 

The requirements above are met by the other options since the SSDS can depend 
on using data system required headers to route the data. 

The other requirement not met is to provide communications services 
symmetrically over the uplink/downlink. The desired autonomy of the space 
station extends to processors onboard to be able to send requests for ground 
based resources without human intervention — computer-to-computer 
communication. This requires such services as verification of receipt and 
retransmission, services normally associated with uplink telecommands. 

Furthermore, the autonomy of the space station is expected to increase over 
time, with functions migrating from ground to space. It is desirable to 
accomplish this migration without requiring extensive modifications to the 
software of functions which intercommunicate. 


4-11 



This implies: 


o providing all services, (such as verified vs unverified delivery) in 
both directions 

o use the same packet/frame format in each direction (currently the 
formats are different for the uplink/downlink) 

o implementing an addressing scheme that can be used for either space 
or ground 

2.1.2 Impacts On SSDS Elements 

The payload always has a packet format, whether it is in the laboratory or in 
the Space Station or platform. This simplifies testing. This is not true for 
the other two options. The same is true for the core interfaces. 

The on— board LAN must carry the CCSDS packet header information, while the 
other two options do not. Since the source packets are long, this does not 
appear to be significant. For example, take two sample packets lengths of 12, 
800 bits and 4000 bits (taken from the Gamma Ray Observatory ) . In this case, 
the overhead for the primary header is .375% and 1.2%, and the secondary 
header (ancilliary data) is 1.375% and 4.4% respectively. 

The on-board gateway (uplink/downlink) is less complex for the downlink for 
this option than for the other two options. In the design, the gateway must 
re-assemble the original source packet (and remove the on-board LAN headers) 
and perform the framing and channel encoding. In the other two options, the 
gateway must also create each packet including adding the relevant ancilliary 
data. While this approach has been used by some spacecraft (packetization by 
central processor), it actually can reduce the value of the packet telemetry 
approach. For example, one might add the same ancilliary data to each packet, 
and make all the packets of the same length as opposed to making these items 
customer or payload specific. Another result is that the payload interface 
changes, as noted above. 


4-12 



The on-board gateway, on the uplink, must read the packet destination ID and 
incorporate this into the ISO headers. The complexity appears slightly 
greater for the proposed option than for the other options since a translation 
must be done between the application address and the on-board location. 

The ground gateway for the design, and the ground processing required to route 
downlink data is greater for the proposed design than for other options. A 
translation must be done for both uplink and downlink between the application 
ID and the ground location. 

The ground reception point must act as the intelligent interface or gateway 
between the data distribution network and the TDRSS uplink/downlink. With 
multiple TDRS and two l\IG1 the mapping between TDRS channels will be very 
dynamic. The COP, POP, or SS might be using one NGT at one time, and other at 
another time. Scheduling all this may be very difficult, so that the right 
data goes to the right customer or RDC. 

The gateway, in the DHC will be required to perform: 

o data capture 

o interface to both IMGTs 

o separate SS from non~SS data (on a scheduled basis) 

o remove the CCSDS frames and channel coding 

o read the source application ID on the CCSDS Packet 

o from a look-up table maintained by Ground Facilities Management, 
determine the destination 

o Based on the destination, send the data to the right port for that 

data. Different options exist for network switching and routing the 
data depending on the data type and characteristics . 
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o 


Provide the physical, data link, and network interfaces to the data 
distribution network or subnetwork used, e.g. 


- if the data is sent on a fixed or scheduled point to point link 
through a mux, send the data to the right mux port 

if the data is sent on a circuit switched link, interface to the 
circuit switch and set up the call 

- if the data is message switched, add the necessary data link and 
network headers (based on the inferred source ID) and send it to 
the message switch 

- if the data is to be packet switched, add the necessary data 
link and network headers, set up a virtual connection to the 
endpoint, and transfer the data 

The inverse functions would have to be performed for the uplink. That is, 
packets or data streams would be routed to the DHC, these would be put in the 
right format for the uplink. One might apply the on-board ISO headers at the 
DHC, or more likely at the on-board gateway as noted above. The data volumes 
for the uplink are much less, requiring less processing. 

All these functions are needed to meet the requirement that the customer be 
able to interact with the payload in essentially the same manner as in the 
laboratory . Thus one is required to have an end-to-end session between the 
payload and the ground control point. 

The functions at the DHC are somewhat simplier for the other options since 
they assume a direct translation between the uplink/downlink protocols and the 
on-board and WAN protocols. Protocol conversion is required but it may be 
possible to do this without scheduling or a table lookup. 
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2.2 How Should Standards Be Implemented? 


The first issue on implementing the proposed design is whether the CCSDS 
standards are implemented as part of the application data or as application, 
presentation, or transport layer standards. 

One possible difference in terms of requirements is that two additional 
requirements are met if the formats are implemented as standards rather than 
part of the application data: 

o the SSIS/SCS data handling shall be independent of the format or 
content of the customer data (CRSS) 

o the data network shall be able to transport and deliver data sets 
intact, without having any knowledge of their internal format or 
content (CRSS, 2. 2. 3. 4) 

The practical impact of this view is programmatic : 

o If the formats are truly implemented as "application data" there 
will be no means to insure that the customers actually use these 
formats. In fact some advocate that customers may be using many 
formats . 

Taken to the logical extreme, this view could prevent the SSDS 
from even delivering the data. The SSDS is dependent on being 
able to read the source application ID, for example. 

o If the packet formats are implemented as required SSDS standards, 
then : 


the SSDS must certify that the payloads are in fact formatting 
the data properly 

the SSDS may consider providing source code to do the formatting 
of the customer data 
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Accordingly, it is recommended that the telemetry formats (present or 
modified) be adopted as SSDS standards. The only technical impact occurs if 
the telemetry standard is implemented as a transport level standards. In this 
case, it would be implemented in the NIU. This would also mean that the 
packetization would no longer be done by the payload but by the SSDS. 

However, instead of being done by a central gateway (as discussed previously) 
the telemetry packetization is being done in a decentralized manner. 

2.3 What Standards Should Be Used? 

We consider standards applicable to three major areas: 
o Flight segment local area networks 

o Terrestrial local area networks 

o Terrestrial wide area networks 

This differentiation is essentially driven by limitations of underlying data 
transmission media and switching equipment. More uniformity of standards is 
feasible in the flight segment LAN's while a diversity of standards must be 
tolerated in terrestrial LAN's. Bandwidth contraints and limitations of 
commercially available switching equipment are significant constraints for the 
terrestrial WAN's and LAN's while realiability and availability of 
space-qualified hardware are more significant constraints for the flight 
segment LAN's. Although highei — levels of the ISO/OSI model are important, 
standards are still poorly developed and we concentrate on the first few 
layers (physical, data link, network) in this section. 

The TDRSS and direct user links essentially are noisy gateways between these 
networks. The design of these links is driven both by the limitations of the 
underlying physical links and requirements for protocol translation. Needs 
for user transparency , efficient high speed protocol translation, and eventual 
migration of ground functions to the flight segment, dictate that these 
standards and related addressing conventions be as uniform as possible across 
all three sets of network components. 
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2.3.1 Flight Segment Local Area Networks 


A major tradeoff for flight segment LAN's is in physical media, in particular 
whether fiber optics should be used in place of traditional coaxial, twisted 
pair, or multiline electrical bus structures. Use of fiber optics for space 
segment LAN's has a number of advantages, including feasible bandwidths of up 
to 10 gigabits/second and immunity to electromagnetic interference . However, 
there are a number of disadvantages. Feasible topologies for fiber optics 
LAN's are pretty much limited to star and token ring configurations. This 
limitation will probably continue until research in methodologies for tapping 
fiber optics cables leads to new connector solutions. Unfortunately, there 
are no widely accepted standards for fiber optics bus protocols and it seems 
likely that NASA will have to create its own (e.g., the Goddard FODS system) 
or use a military standard (e.g., MIL-STD-1773) . 

The primary set of standards likely to be of use for high-level ISO layer 
flight segment LAN standards are the (1) IEEE 802 family of protocols which 
include multiple physical link protocols united by a common data link protocol 
(IEEE 802.2) or (2) the ANSI X3T9.5. Although the collision sense and token 
ring protocols associated with IEEE 802 may not be appropriate under the 
constraints of flight hardware and the bandwidth requirements of the SSDS, the 
data link protocol provides the definition of a critical layer of the flight 
segment LAN which will make ground and flight segment application transparency 
feasible in the later phases of the Space Station program. Alternatives 
include use of variants of current avionics system buses (e.g., the MMS bus or 
MIL— ST— 1553 ) . The critical element of this tradeoff is the support of a 
common set of ground and flight segment protocols which is likely to 
substantially simplify development and network simulation activities, provide 
a more uniform development environment, and lay the basis for migration of 
ground segment functions to the flight segment. 
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2.3.2 Ground Segment Local Area Network Standards 


The ground segment LAN structure is likely to be significantly less uniform 
than the flight segment LAN. The IEEE 802 family again seems to provide the 
most straight forward set of solutions, since they provide a broad set of 
physical link layer solutions, and have been implemented on most major 
vendors' processors. The IEEE 802,3 protocol (Ethernet) provides adequate 
bandwidth and response characteristics for workstations, while the IEEE 802.4 
token but protocol provides a more predictable response pattern suitable for 
control networks. Additional physical layer protocols (e.g., fiber optics 
protocols) can be provided for enhanced bandwidth, but maintaining the same 
data link layer protocols. 

2.3.3 Wide Area Network Standards 

The major issue associated with wide area network standards is feasible 
bandwidth. A leading candidate for an SSDS wide area standard is the X . 25 
packet standard. Current commercial implementations of X.25 provide service 
at rates up to 56 kilobits per second. Although higher data rates are 
feasible, the bandwidth of X.25 is constrained by feasible switching rates, 
buffering requirements , and handshaking procedures. It is unlikely that rates 
over a megabit per second can be supported within the forseeable future. For 
example, support of a 50 meagabit/ second X.25 data rate with maximum length 
X.25 packets requires hardware capable of switching a packet every 20 
microseconds, a requirement not easily filled with existing hardware without 
extensive use of parallelism. Buffering associated with maintaining virtual 
circuits and handling transmission errors at these rates presents similarly 
difficult problems. 

Alternatives essentially are point-to-point links (such as are currently 
provided for high-rate NASCOM services) or circuit switched service. The 
weaknesses of these services are their lack of full error correction, and 
relative lack of rapid route dynamicism in response to system faults and user 
requests for services. 
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A major tradeoff for the SSDS thus involves the use of packet standards for 
wide area networking versus relatively static switching mechanisms. For 
example, links between the White Sands DHC and the Regional Data Centers are 
likely to be relatively static and not require sophisticated dynamic or 
alternative routing. Circuit switching standards may be appropriate. Another 
feasible alternative is to define multiple classes of X.25 services, removing 
elements of the X.25 protocol (e.g., dynamic routing or acknowledgement 
services) in order to achieve satisfactory performance for high data rates. 
This would be more akin to a message switching or datagram ("connectionless") 
approach. 

The high rate experiments (300 Mp/s) may or may not be sent in this form of 
telemetry packets. Wide area standards for this data may be limited to 
transport (e.g., statistical multiplexing) as opposed to switching (network) 
standards . 


4-19 



3.0 RESULTS 


3.1 Implementation Options 

The first option (CCSDS packets implemented as an ISO upper layer standard) is 
recommended since it appears to have the best fit with requirements and the 
most balanced set of impacts. However, some changes must be made to how the 
option is implemented. 

3.2 How Should Standards Be Implemented? 

The telemetry formats (present or modified) be adopted as standards at some 
level of ISO structure above the transport layer. This will meet the needs 
for programmatic verification of the formats but still meet the full range of 
requirements . 

The available standards should be selected so that they: 

o provide all services, (such as verified vs unverified delivery) in 
both directions 

o use the same packet/frame format in each direction (currently the 
formats are different for the uplink/ downlink) 

o implement an addressing scheme that can be used for either space or 
ground 

3.3 What Standards Should Be Used? 

For the ground segment it appears feasible to adopt an evolutionary approach, 
expanding the quality of services as packet switching technology improves. A 
distinction between high and low data rate services which is 

technology-dependent could be adopted; high data rates would simply be defined 
as those for which standard X.25 services could not be provided with 
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off-the-shelf switching equipment. High data rate users would be limited to 
non-dynamic services although they would have access to low rate command and 
data transfer channels which would provide fully transparent packet network 
support. As switching technology improves (or as new high performance packet 
standards are introduced) further capabilities for high rate service could be 
introduced with the net effect of removing the distinctions between high rate 
and low rate services. 

4.0 Conclusions, Recommendations & Issues 

In their current form, none of the options support the following services as 
customer selectable options: 

o quality of transport service (computer quality vs normal quality) 

o delivery service (immediate delivery vs store & forward delivery) 

The feasibility of modifying existing standards so that the above services are 
supported . 

The selection of the wide area network standards is dependent on the detailed 
design of the wide area data communications network, which is outside of the 
SSDS. The issues discussed in Section 2.3 are drivers to this design and 
interact with the design of the SSDS elements. 
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V. ONBOARD LOCAL AREA NETWORKING 
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ONBOARD LOCAL AREA NETWORKING TRADE STUDY 


1 . INTRODUCTION 

The purpose of this trade study is to identify and explore the major issues 
associated with the Space Station onboard local area network. 

1.1 BACKGROUND 

A local area network is an information transport system for information 
transfer between devices. LANs generally provide high-bandwidth communication 
over transmission media. Multiple LANs may be interconnected by gateways/ 
bridges providing an interconnecting vehicle for a wide variety of 
communications devices. The Space Station onboard LAN must provide features 
such as high performance, modularity, fault tolerance, and evolutionary growth 
capability, all at low costs. 

Local area networks basically consist of transmission media. Network Interface 
Units (NIUs), and the Network Operating System (NOS) (See Figure 1). The NOS 
is also discussed in the Distributed Operating System Trade Study. 

The transmission medium of a LAN is the element of the network which carries 
the physical signals between nodes. Options for transmission medium include 
twisted shielded (TSP) pair, coaxial cable and fiber optics. Concurrent with 
the Space Station Reference Configuration Document, this trade study assumes 
that the prime LAN transmission medium for the onboard system will be optical 
fiber. Optical fiber provides a high bandwidth, highly secure medium for data 
communications. However, other media are not precluded for specific subsystem 
and payload controlled back-end local LAN’s. The 1.7. 1.1 Network Transmission 
Medium option paper provides media comparisons. 
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Data system components are attached to the transmission media via Network 
Interface units (NIUs). The NIU utilizes standard protocols to interface host 
devices to other host devices. Host devices are attached to the back-end of 
an NIU and can include SSDS standard processors, user-supplied processors, 
mass memories, sensors and effectors. Non— homogeneous devices are not 
necessarily precluded because an "open system" is a major goal. The 1.7. 1.2 
Network Interface Unit option paper provides additional background. 

1.2 ISSUES 

Major issues that were considered in developing alternatives for this trade 
study include the following: 

1. Topology - Physical and Logical (star, ring, bus, etc...) 

2. Transmission Medium - TSP, optical fiber, etc... 

(baseband or broadband) 

3. Multiple LANs or one global LAN for the Space Station. If multiple, 
same or different protocols, data rate, medium...? What are the 
Bridge/Gateway functions? 

4. Performance - The LAN must integrate a wide variety of equipment 
types, ranging from sensors with data rates of less than one bit/sec 
to experiments with possibly data rs^tes of hundreds of millions of 
bits/sec. User data rates are given in the mission data base and 
SSDS function-related data rates were developed in TASK 1. 

5. Standardization/commonality - within Space Station and among SSPE's; 
can impact maintainability costs 

6. Protocols and end-to-end compatibility, including use of the 
Consultive Committee for Space Data Systems (CCSDS) and the ISO/OSI 
reference model. 

7. Media Access Method - Token Passing, CSMA/CD, Laning Poll,... 

8. Connection or Connectionless services 

9. Are voice, video and data integrated onto one network? 

10. What functions does the NIU perform? (versus host?) 

11. Back-end interfaces standards versus subsystem unique 
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1.3 TRADE STUDY CRITERIA 


Each alternative was evaluated using the following two groups of criteria: 
1.3.1 Generic 

The generic criteria across all trades are: 

Cost . 

- development 

- unit 

- life cycle 

Risk . 

- development 

- production 

- technology readiness 

Growth/Technology Insertion Potential. 

Standardization/Commonality . 

1-3.2 Trade Study Uniqu e 

The criteria that are unique to this study are: 

Environmental Characteristics . 

- Radiation Tolerance 

Other Space Qualified Parameters 

Performance and Delay Characteristics . 

- connectivity 

- reconf iguration 
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Physical Characteristics . 

- weight, power, size 

Reliability/Avai lability /Maintainability . 

- fault tolerance 

1.4 APPLICABLE OPTION PAPERS 

Several Task 2 option papers are applicable to this trade study. The total 
list is: 


o 

1.7. 1.1. 

Network Transmission Medium 

0 

1.7. 1.2. 

Network Interface Unit 

o 

2.1.3 

Distributed Operating System 

o 

2.2.3 

System Growth 

o 

2.2.5 

System Interfaces 

0 

2.3 

System Security/Privacy 

o 

2.4 

Time Management 

o 

2.5.2 

Local/Remote Area Communication 

o 

2.5.3 

Local Area Networks 

o 

2.6 

Network Performance Assessment 

o 

3.1 

Standardization/Commonality 


The prime option paper is of course, 2.5.3 Local Area Networks. Also of 
particular interest are the first two above, 1.7. 1.1 and 1.7. 1.2. 
Effectively, the subject LAN Trade Study also covers these areas. 

1.5 ALTERNATIVES 


The onboard network trade study will be divided into the nine sections listed 
below. The alternatives in each section are also listed. 
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(1) Configuration 


How is the Space Station onboard LAN configured? 

Options: - Multiple LANs interconnected by bridges/gateways. 

- A single Space Station LAN. 

(2) Standards 

If the Space Station network consists of multiple LANs, should they 
all follow the same standard? 

Options: - Single standard for LANs 

- Multiple standards for LANs 

(3) Topology and Media Access Method 

What are the topology and media access method for the onboard LAN? 

Topology Options: 

- Star 

- Bus 

- Ring 

- Mesh 

- Star -wired-ring 

Media Access Method Options: 

- Token Passing 

- Slotted Ring 

- Register Insertion 

- Polling 

- Laning Poll 

- CSMA/CD 
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Combinations of the above parameters were evaluated followed by "an assessment 
of government and industry sponsored technology developments" (Ref. 8) 
resulting in the following options: 


- Token Ring 

ANSI X3T9.5 FDDI 

- Token Bus 

IEEE 802.4 Token Bus 

- Laning Poll Bus (logical) 

AIPS 

SubACS 

- CSMA/CD/TS Bus 

PODS 

- Langley Mesh 

- Others 

SAE/AE-9B 


(4) Voice/Video 

Are voice and video integrated on the data network or handled 
separately? 

Options: - Voice/Video/Data Integrated 

- Voice/Video handled separately from data 

(5) Communications Functions 

What functions in terms of ISO/OSI Layers are performed by the 
communications network? 

(6) Network Interface Unit 

What functions are allocated and performed by the NIU? Should there 
be a less complex NIU for simple I/O devices? 
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Options : 


- One NIU for all applications (core and payload) 

— Less complex l\IIU for sensors and effectors (core) 

- Separate NIU for Customers 

(7) Connection - Oriented vs Connectionless Service 

Which type of service best satisfies the needs of the Space Station 
LAN users? 


Options: - Connection - Oriented 

- Connectionless 

(8) Back-end Interfaces 


How are devices connected to the backplane bus? 

(Considered only recognized external connections, no internal) 


Options: - IEEE 796 

- IEEE 488 

- IEEE 595 
(EUR 6100) 

- IEEE 596 
(EUR 4600) 

- IEEE 683 - Customer Supplied 

(EUR 4100) 


MIL— STD— 1553 B 
MIL— STD— 1773 
RS— 232 
RS— 422 


(9) Protocols and End-to~End Compatibility 


2.0 METHODOLOGY 


This trade study incorporated the results of the NIU, Transmission Media, and 
LAN Task 2 option papers in determining the major issues to be resolved in 
defining the Space Station onboard LAN and the alternatives in each area. 

Each of the alternatives was evaluated in order to identify its advantages and 
disadvantages . 
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The advantages and disadvantages were identified through the team experience 
base in the data communications field, interviews with experts, and through 
literature surveys, 

The advantages and disadvantages were then analyzed in terms of the trade 
criteria in order to arrive at prioritized options for the onboard local area 
network . 

3.0 RESULTS 

A summary of all the results in this section is tabulated in a set of decision 
matrices in Appendix A of this trade study. The following sections discuss 
those results in more detail. 

3 . 1 Configuration 

There are two alternatives for configuring the Space Station communications 
system. It could be configured as one large local area network spanning the 
entire Space Station or it could consist of multiple LANs interconnect by 
bridges/gateways . 

One large local area network would provide for easy routing since everything 
would be connected to the same LAN. This configuration however, has the 
disadvantage of lower reliability. If there is a link failure, the entire 
Space Station data communication system could be affected. Another 
disadvantage is that changes to the system, such as adding a new node or 
reconf iguring it, affects the whole communications system. Also message 
delays will generally be larger because there are more nodes contending for a 
single network. 


On the other hand, multiple LANs interconnected by bridges/gateways would 
require more complex routing, but it would be easier to reconfigure. Adding a 
new node to a LAN or a new LAN would only affect the local LAN, not the whole 
Space Station communications system. Multiple LANs are also more fault 
tolerant; if one LAN fails, the other LANs are still operational. Multiple 
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LAIMs would not only enhance security since the payload and core could be on 
physically different LANs, but also carry a higher net aggregate overall 
traffic rate. Also, local LAN messages stay in the local LAN and do not 
impact message rates or' performance on the other LANs. Multiple LANs also 
provide easier connectivity for Space Station build-up and allow a lower level 
of integration during development and build-up. It is expected that some 
grouping of payload sensors will be integrated into a single LAN and thus ease 
their attachment to the total network. 

Considering the advantages and disadvantages above (summarized in Table A- 1), 
the multiple LAN communications system is best suited for the Space Station. 
The multiple LAN configuration allows for easy build-up if the system were 
designed such that the LANs corresponded to modules. One or more LAN's per 
module also meets the safe-haven requirements with each bridge/gateway acting 
as an isolator. This multiple LAN approach is basically consistent with the 
Space Station Reference Configuration (Reference 5) two network systems — a 
housekeeping (core) network and a payload network. 

3 . 2 Standards 

With multiple LANs on the Space Station, should one standard apply to all 
LANs, i.e. should they all have the same topology, protocols, etc...? Having 
a single standard for the onboard LANs satisfies commonality requirements , It 
also allows for a simpler bridge to provide interconnection between the LANs. 
Since all LANs have the same protocols, no gateways are required. 

This alternative, however, may not be the best solution in the long run. As 
the data rate requirements evolve with Space Station growth, a single standard 
for onboard LANs may not satisfy these requirements . Also, this may suppress 
domestic and foreign customers. If multiple standards were allowed the LANs 
could be optimized to meet specific requirements . The costs could also be 
lower since commercial standards may be allowed. Multiple standards also 
allows for technology insertion in growth; new LANs could utilize state of the 
art technology. 
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However, the multiple standards alternative also has some drawbacks. It would 
require more complex gateways to interconnect the LANs. The gateways must 
provide flow control and storage since the data rates and protocols may 
differ. The necessity for gateways could increase the overall net cost of the 
system. 

The advantages and disadvantages of each standard policy alternative are 
summarized in Table A-2. 

Each alternative has some advantages. The single standard for LANs provides 
the most cost-effective solution while meeting the commonality requirement. 
Therefore, at IOC, one standard should apply to all LANs. This 
recommendation, however, does not preclude the use of multiple standards for 
LANs beyond IOC. Since future requirements may vary, multiple standards in 
growth are the only practical solution. This also allows for easier 
technology insertion. As more data becomes available from the customer 
community, the need for perhaps a second standard for the payload network 
should be studied. 

3 . 3 LAN Topology and Media Access Methods 

The topology of a network determines the manner in which the stations (nodes) 
of the network are interconnected. There are many ways to interconnect nodes 
depending on the communications requirements , reliability, medium, and 
redundancy of the network. The four basic topologies are the star, bus, ring 
and mesh (see Figure 2). Variations and combinations of these basic 
topologies can yield useful improvements in performance and should also be 
evaluated. For a description of the topologies See the Task 2 LAN Option Paper. 
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The active star will not be further considered for primary use on the Space 
Station because of its inability to tolerate faults; it relies on the central 
node (single point of failure). However a star LAW is not precluded for a 
payload user group with provision for a gateway interface. 

The manner in which devices gain access to the medium is determined by the 
network protocol. Access to the medium may be either controlled or demand 
access. With demand access techniques such as CSMA/CD, a node attempts to 
gain access whenever it has a message to send. With controlled access such as 
token passing or polling a predetermined method is used to award access. The 
media access protocol options considered here are: 

- Token Passing 

- Slotted Ring 

- Register Insertion 

- Polling 

- Laning Poll 
CSMA/CD 


The performance, reliability, and complexity vary with each protocol. For a 
description of these media access methods, reference the LAW Option 
Development . 

Some of these media access methods do not meet the Space Station requirements 
as well as the others. The slotted ring, for instance is wasteful of 
bandwidth. The register insertion method requires a complex purge mechanism 
to discard continuously circulating packets, and the polling protocol has a 
high overhead and is not fault tolerant. CSMA/CD is non-deterministic , (the 
maximum delay before gaining access to the medium cannot be calculated), has a 
low utilization at high loads, and does not allow priorities. Due to the 
major disadvantage of these media access methods, they will not be considered 
further. It is recognized that other variations on CSMA/CD exist, e.g., 
CSMA/CA (Collision Avoidance) and CSMA/DP (Dynamic Priority). These tend to 
be more deterministic, but not as much as a token ring. 
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The media access protocol and the network topology are interrelated ; not every 
topology allows the use of every media access protocol. Since they are 
interrelated, they cannot be evaluated separately, and will therefore be 
evaluated together. The alternatives considered in this trade study are: 

Token Ring 

o ANSI X3T9.5 FDDI 

Token Bus 

o IEEE 802.4 

CSMA/CD/TS Bus 
o FODS 

Laning Poll Bus 
o SubACS 

o AIPS 

Langley Mesh 

Others 

o SAE/AE-9B 

A description of each is contained in the LAN Option Paper and Table 1. 

The advantages and disadvantages of each of the above alternatives are 
summarized in Table A-3 of Appendix A. 

The LAN speed of each system is not a key factor except for the IEEE 802.4 
token bus which typically operates at only 5 Mbps (Ref. 4). This data rate is 
obviously too low to effectively meet the Space Station requirements . The 
other networks, however, have essentially the same maximum data rate of 
approximately 100 Mbps except SAE/AE-9B which has specified the data rate to 
be greater than 13.6 Mbps. 
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Table 1: LAN Characteristics 
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The cost of the systems does not appear to be a key factor either. The cost 
of the standard systems, ANSI and IEEE may be slightly less than the others, 
but the difference will not be significant. The AIPS system is proposed for 
use throughout the space industry lowering its cost. SubACS is already highly 
developed thus, lowering its overall cost too. The FODS system may be 
slightly more expensive due to the complexity of the NIU, and the Langley Mesh 
may also have a higher cost due to the node electronics. The SAE/AE-9B system 
is not well enough defined to be evaluated. 

The complexity of the systems vary greatly. SubACS, for instance, has very 
complex NIUs . The SubACS NIU contains over 1100 Integrated circuits. The 
FODS system will also have complex NIUs due to the dual modes. The Langley 
Mesh may require complex routing algorithms. The complexity of the other 
systems is comparable. The complexity effects cost, reliability, risk, and 
growth/technology insertion potential. An example of the complexity 
variations is the dynamic range problem associated with the number of devices 
on a bus. 

The complexity of the optical receivers varies as a function of topology. 
Optical receivers have different sensitivity range requirements depending on 
the topology of the connecting network. If the strength of the received 
signal varies, the receiver must adjust its circuitry to properly convert the 
optical signal to an electrical one. 

With point to point links such as those in the ring topology, signal strength 
varies very little, and simple receivers can be designed. In the linear bus 
topology, on the other hand, nodes tap into the network and cause a typical 
signal strength degradation of 1 dB. Addition of several nodes in a network 
might cause a receiver that does not have automatic gain control ( AGC) to 
erroneously detect a signal. 

A passive star network normally does not have this problem because the loss is 
independent of the number of nodes attached to the star. If the number of 
nodes that need to be attached is greater than what the system can support and 
•the n node star is replaced by an m node star (with m > n), the additional 
loss may also require receivers with AGC. 
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For this reason, the ring topology has an advantage over the bus and passive 
star. The ring's simpler receivers would be lighter, simpler, and more 
reliable. The active star generates signals at the central node, so AGC would 
not be needed there either. Note that even a receiver with AGC will have some 
limitations. A typical sensitivity range with AGC might be 20 dB or more, but 
only 2 - 10 dB without AGC. 

The fault tolerance/reliability of the onboard LAN must meet the FO/FS/R 
requirement. Most of these systems provide some means for fault tolerance. 
ANSI allows nodal bypass switches, counter-rotating rings and ring 
concentrators . Triply redundant networks exist in the AIPS specification. 

The Langley Mesh provides redundant paths as does SubACS. The SAE/AE-9B 
system will also provide fault tolerance but the means have not yet been 
specified , 

However, few of these systems meet the FO/FS/R requirement (AIPS, SubACS and 
possibly the Langley Mesh). In order to meet this requirement, the redundancy 
of the other LANs must be increased. The ANSI system, for instance, will 
operate with one and possibly two faults. In order to guarantee safe 
operation after two faults, a third ring must be included, ie. a triply 
redundant network. Similarly, FODS provides redundant networks, but to meet 
this requirement a third redundant network would have to be included. It is 
assumed that all systems will be configured with appropriate redundancy levels 
in order to meet the FO/FS/R requirement . 

Consequently, evaluating the reliability/maintainability/availability of the 
alternatives requires analysis of the reliability of the components. With the 
IEEE token bus, for instance, the failure of a node adversely affects the 
logical sequencing of the nodes required for token passing on a bus. The 
FDDI, allows wiring concentrators . While providing ease of maintenance and 
growth technology insertion, the wiring concentrators decreases the 
reliability of the system; if it fails, the connected network could be 
disabled . 
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The passive star used in SubACS and FODS is also a possible central point of 
failure, but since it has no electrical or moving parts, the chances of 
failure are much less. While the passive star increases reliability, it 
decreases growth/technology insertion potential because of the signal division 

amonq the nodes. If the number of nodes (m) that need to be attached is 
greater than the number of ports (n) on the passive star, the n port star must 

be replaced by an m port star. Passive stars cannot be connected serially due 
to the power losses. On the other hand, wiring concentrators in a ring may be 
connected serially since each node acts as an active repeater. 

The link access performance of the FODS and FDDI systems (ISO Layers 1 and 2) 
were analyzed (Reference 13). Some results are presented in Figure 3. These 
two sub-figures indicate that no significant performance differences in mean 
throughput and mean service time exist between the two systems. Further 
comparisons between FODS and FDDI are shown in Appendix B of this trade study. 

A major advantage of some systems is standardization. The ANSI system, IEEE 
802.4 and SAE/AE-9B are all (or will be) standards. A system which is a 
standard provides a higher growth potential. Standard systems are also 
usually lower in cost and risk. 

The physical characteristics of these systems are not well enough defined to 
be compared. The power requirement for the current SubACS system (300 watts) 
exceed the power specified in the Reference Configuration (Ref. 5). It is 
likely that the implementation of any of the other LAN systems with the same 
level of SubACS services would require about the same power level (VLSI 
technology) . 

Each alternative was evaluated using the criteria. The criteria were divided 
into three categories: Cost, status, and technical. The categories were 

allotted 300, 200, and 500 points out of 1000 respectively. A breakdown of 
the categories and points scale follows: 
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Figure 3. Performance Comparison for the ANSI Standard X3T9.5 Token Ring and the Fiber Optic Demonstration 
System (FODS) Bus Protocols. Network Parameters Simulated Were: 5 BIUs; 2048 Byte Packet Size; 100 Mbps 
Transfer Rate 
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Cost 


Cost 200 

Standard izat ion/Commonal i ty Ipo 

300 

Status 

Risk (Technology Readiness) 200 

200 


Technical 

Performance 100 

Growth/Technology Insertion Potential 100 

Re liability /Maintainability /Availability 100 

Physical Characteristics 100 

Environmental Considerations 100 

500 

Maximum Points 1000 


The LAN evaluation results are shown in Table 2. Additional data are 
necessary to complete the table. 
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TABLE 2: LAN EVALUATION 
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^SUBTOTAL - DOES NOT INCLUDE COST, PHYSICAL CHARACTERISTICS AND ENVIRONMENTAL CONSIDERATIONS. 



After examining the key advantages and disadvantages of each alternative in 
Table 2, the highest score was achieved by the ANSI X3T9.5 FDOI system and it 
appears to best meet the Space Station requirements . ANSI X3T9.5 scores well 
across all the criteria, a 15% reduction in each FODI score would still yield 
the highest total score. It is standardized, deterministic, fault tolerant 
and has good performance. It handles high data rates (100 Mbps) and does not 
require excessively long wiring lengths. 

As the Langley Mesh and SAE/AE-9B are defined and developed they should be 
re-evaluated for possible use on the Space Station in growth. 

3 . 4 Voice/Video 

Should voice/video and data be integrated onto the same networks? 

If voice and video were transmitted on the same network as data, less wiring 
would be required. This would reduce the cost, but more complex hardware 
would be required, increasing the cost. The video bandwidth requirements 
would load the system and possibly inhibit growth. 

Alternatively voice/video could be transmitted on one network and data on a 
separate network. This configuration would require more wiring but simpler 
hardware since each system would be baseband. Another advantage of this 
alternative is that the transmitters and receivers could be optimized for each 
application . 

The advantages and disadvantages are summarized in Table A-4. 

The advantages of separate networks outweigh the disadvantages for application 
onboard the Space Station. The electronics for separate networks would be 
simpler, better known, and, therefore, cost less and have a higher 
reliability. This configuration also allows for optimization of each system 
which will provide better performance. 
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3,5 Communications Functions (ISO/OSI) 


The functions performed by a communications system can be described in terms 
of the ISO/OSI model. The Open Systems Interconnect Model consists of seven 
distinct’ layers each performing at set of unique functions. The layered 
architecture provides flexibility in revising the system. As long as the way 
information is passed between the layers is not affected, only the appropriate 
layer needs to be altered to implement the change. This provides the ability 
to continuously incorporate new technology into the existing system. 

The ISO/OSI layers and the possible functions performed by each layer are 
shown in Table 3. Some layers or some functions designated to a particular 
layer may not be present in some systems. For example, negotiation for 
character code conversion (presentation layer) would not be necessary if all 
systems used the same character set. If the need arises, functions or layers 
not initially present could be added. Similarly, the Space Station onboard 
local area network may not require all of these functions. In order to 
provide a high performance system at the lowest possible cost, only the 
necessary software services should be provided at IOC. The hardware should be 
sized at IOC so that other software services may be added when necessary as 
the system grows. The ISO/OSI functions and their classification of present 
at IOC or possible incorporated in growth are shown in Table 4. The growth 
column entries in Table 4 are possible services that may be added after IOC. 

The column entries in Table 4 represent a collected view among the study team 
members and some NASA and other contractor views. It is of note that for IOC 
a null presentation layer is indicated in Table 4 since data compression (if 
performed) is assumed to be a user provided function. 


5-25 



f— 

I ISO/OSI 
1 

FUNCTIONS 

EXPLANATION 

1 - 


7 APPLICATION LAYER 


Connection Oriented 


-bulk file transfer 
-virtual terminal usage 
-message handling services 
-job transfer and manipulation 
-stream oriented access to devices 

Connectionless Oriented 


-data collection 
-outward data dissemination 
-broadcast / multicast 
-request / response applications 

Connection / Connectionless Services 

-ID of communicating partners 
-Establishment of authority to commun. 

-Authorization of intended partners 
-Application Layer Management - management of resources at 

this layer 

6 PRESENTATION LAYER ~ " 

This layer provides the means for negotiation of syntax and the need 
for the following types of conversion. 

- encryption services 

- data reduction 

- translating to another 
character set 

- conversion between 
different types of graphics 

- management of resources at 
this layer 


security 

data compression 
character code conversion 

graphics syntax conversion 

presentation layer management 


- This type of communication 
involves initial negotiation 
of parameters. The following 
applications are connection- 
oriented: 


This type of communication 
involves no initial nego- 
tiaion of parameters. The 
following applications are 
connectionless oriented: 


These services are utilized 
by both types of data transfer 


1 


Table 3: ISO/OSI Layers (Part 1 of 3) 


5-26 



ISO/OSI FUNCTIONS 


EXPLANATION 


5 SESSION LAYER 

- expedited delivery 

- multiplexing sessions 

- synchronization 

- dialog control 

- binding 

- quarantine service 


- activity management 

- session layer management 

4 TRANSPORT LAYER 

- connectionless management 

- connection management 

- segmentation / reassembly 

- sequencing 

- blocking / deblocking 
* header error control 

- data multiplexing connections 

- expedited delivery 

- resetting 

- flow control 

- error detection / control 

- address mapping 

- service type conversion 

- transport layer management 


1 


- a quick pass-through for 
time-critical data 

- time division multiplexing data 

- synchonization points in data 

- who speaks, when, how long, 
half or full duplex 

- setting up the session 
between two entities 

- provides the means for two 
communicating entities to pass 
blocks of data and to agree, in 
advance, how many blocks are to 
received collectively before an 
are transferred to higher layer 

- allows user to break dialogue 
into discrete activities which 
can be suspended, resumed, begun 

- management of layer 5 resources 


- management of connectionless 
service 

- management of connection- 
oriented service 

- breaks/assembles messages into 
smaller units (segments) 

- assembles segments in proper 
order 

- grouping of small messages into 
one packet 

- monitors errors in transport 
header 

- multiplexing data streams 

- a quick pass-through for 
time critical data 

- indicates to host loss of 
info, due to subnet crash (1) 

- prevents data from arriving 
faster than receiver can 
handle it 

- checking for errors 

- converting logical addresses 
to physical addresses 

- converting to connectionless 
or connection-oriented service 

- management of resources at 
this layer 


Table 3: ISO/OSI Layers (Part 2 of 3) 
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ISO/OSI FUNCTIONS 


EXPLANATION 


3 NETWORK LAYER 


- routing / switching / relaying 

- congestion control 

- packetization / reassembly 


- sequencing 

- header error control 

- quality of service maintenance 

- expedited delivery 

- error control 

- network layer management 


2 DATA LINK LAYER 

- framing 

- error control / notification 

- media access 

- flow control 


- data link layer management 


1 PHYSICAL LAYER 


determined by medium 


determines which path to send 
the packet on 

regulates flooding within the 
network 

breaks data into packets and 
reassembles them 
arranges packets in proper 
order 

monitors errors in the network 

layer header 

monitors error rates 

quick pass-through for time 

critical data 

error checking 

manages resources at this 

layer 


formats data into frames 
error checking 
obtaining control of the 
media in order to transmit 
prevents data from arriving 
faster than the receiver can 
handle it 

manages resources at this layer 


the mechanical, procedural, 
and electical interface to the 
medium 


Table 3: ISO/OSI Layers (Part 3 of 3) 
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Table 4: ISO/OSI Functions (Part 1 of 2) 
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Table 4: ISO/OSI Functions (Part 2 of 2) 


5-30 









3-6 The INIIU 


The Network Interface Unit (NIU) is a device that acts as a communications 
controller to provide data transmission to one or more attached devices 
(subscribers) . This NIU transforms subscriber data rate and protocol to that 
of local network transmission medium and vice versa. Data on the medium are 
available to all devices. 

The NIU can function as a gateway (providing interconnection of multiple 
networks that use different protocols) or as a bridge (providing 
interconnection of multiple networks that use the same protocols). The uses 
of an NIU in a communications network are shown in Figure 1. The functions 
performed by the NIU depend upon what ISO/OSI layers are contained in the 
NIU. (Refer to Tables 3 and 4) One view consists of seven layers in the NIU 
(shown in Figure 4a) for software portability reasons. Another view, 
described below, consists of four layers in the NIU (Figure 4b). Further 
study is needed in this area to determine the optimum configuration. 


There are two categories of application layer service elements: Common 

Application Services Elements (CASE's) and Specific Application Service 
Elements (SASE's). "Common Application Service Elements provide capabilities 
required by application processes for information transfer independent of the 
nature of the application (e.g., setting up an association between application 
processes, terminating an association between application processes). 

Specific Application Service Elements provide information transfer 
capabilities (e.g., file transfer, data base access, job transfer) or 
capabilities to satisfy the needs of particular application processes." 

(Ref. 10) In Table 3, CASE's correspond to "Connection/Connectionless 
Services," and SASE's correspond to all other connection oriented and 
connectionless oriented elements. 

Since the SASE's serve specific application processes, these functions should 
be provided in the host system. CASE's, on the other hand, are utilized by 
all applications processes for information transfers. CASE's should also 
reside m the host. This allows for the initialization of the association 
between applications processes to be done in the device in which the 
application resides , 
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The presentation layer provides the means for negotiations about the syntax of 
information transfers. Where the syntax is incompatible, mapping must occur. 
The actual mapping process, however, does not take place in the presentation 
layer, but in the SASE category of the application layer. The presentation 
layer, therefore, provides the means for syntax negotiations between 
communicating entities using different syntax. Since common hardware and 
software will be utilized as much as possible on the Space Station, 
incompatible syntax will rarely occur. The presentation layer should, 
therefore, reside in the host. 


The session layer can be viewed as "the user's interface into the network" 
(Ref. 5). The session layer provides services such as checking the user's 
right to access the destination and collecting groups of messages so that none 
are delivered until all have arrived. These services are performed for each 
user requiring them. When more than one device is attached to 
the NIU, the presence of the session layer in the l\IIU would unnecessarily 
limit the throughput in order to provide these services for each attached 
device. On the other hand, if the devices perform these functions, several 
messages could be handled simultaneously (one per device) at this layer. This 
layer should, therefore, reside in the host. 

Unlike the session layer, the transport layer is not user oriented, but 
provides the end-to-end communications connectivity of the network. Functions 
such as segmenting messages, multiplexing, and flow control are performed. 

This layer performs standard communications functions and should, therefore, 
reside in the NIU. 

The network, data link, and physical layer are concerned primarily with 
routing, media access and the physical connection to the media respectively. 
These functions are clearly communications functions which should be performed 
by the NIU not only to alleviate the loading of the host but also to provide a 
standard communications interface. (See Table A-5) 


5-32 



The division of layers between the host and NIU at the transport-session 
layers (shown in Figure 5) provides the network transparency , i.e., the host 
need not be aware of the network topology arid protocol. This allows for 
standardization of the NIU hardware and software. Since the NIU would handle 
all of the communications protocol, it could support simple digital I/O as 
well as intelligent hosts. This configuration of the NIU is also functional 
as a gateway/bridge, which would require only layer 1-3. 



Figure 4a. Option 1 for Division of Layers Between NIU and Host 
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IN HOST 



RESIDENT 
IN NIU 



Figure 4b. Option 2 for Division of Layers Between Host and NIU 
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ISO TRANSPORT LAYER ALTERNATIVES 
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The Nl'U shall also time-stamp all messages. This is further discussed in the 
Time Management Task 2 Option Paper 2.4. 

3 . 7 Connection Mode 

There are two alternative modes of connection for networks, 
connection-oriented and connectionless. 

Connection-oriented service involves the initial setup of an association 
between the parties involved before actual data is sent. Once the association 
is established, it is held for the duration of the transfer. 
Connection-oriented service "allows for negotiation of parameters and options 
(such as grade of service). It provides a context for sequencing and flow 
control of transmitted data units, and it has a clearly distinguished 
lifetime". (Ref. 3, p. 15) Connection-oriented service provides the 
advantage of preallocating resources. At transfer initiation, if the 
resources are not available the message is not sent. This, however, requires 
more overhead than connectionless service in order to initialize the 
transfer. Connection-oriented service also allows for error detection and 
retransmission requests earlier than connectionless service (because 
sequencing can be done in layer 3). 

Connectionless service requires no negotiation of parameters at the time the 
service is accessed. Each party has "knowledge of the parties with which it 
may communicate" and "has the explicit knowledge of the characteristics of the 
service it can expect to be provided with each invocation of the service". 

(Ref. 7) Each unit of data is independent and self-contained. 

Connectionless service uses less bandwidth since there is no initial transfer 
setup. Another advantage is that connectionless protocols are simple to 
implement. Error control and sequencing must be provided at a higher layer 
(layer 4) since each packet is sent independently. This however, should not 
be a major disadvantage on Space Station since the LAN will provide a robust 
transmission medium. (The advantages and disadvantages are summarized in 
Table A-6) 
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Connection oriented service at the Data Link layer implies sequencing and 
error control at this layer. Due to the robust nature and low bit error rate 
of the transmission medium, these services need not be performed at layer 2, 
but can be provided at a higher layer (layer 4). Therefore, connectionless 
service at the Data Link Layer will provide reliable yet efficient 
communications at this layer. 

Connection oriented service at the network layer allows large networks (such 
as multiple LANs interconnected by bridges) to be operated as one large 
network with deterministic global resource allocation. When routed, each 
packet of a message follows the same path. Each packet transmitted through a 
connectionless network layer is routed independently. For the onboard LAN, 
connectionless service at the network layer will provide efficient services 
with less overhead. 

At the transport layer, connection oriented service implies end-to-end flow 
control, sequencing, and error checking. Since these essential services are 
not provided by the connectionless network and data link layers, the transport 
layer should be connection— oriented . Of the ISO Transport Layer classes of 
service shown in Figure 5, Class 4 will provide timely and reliable data 
transfer for mission critical data. The functions available with Class 4 
service include data transfer with segmenting, multiplexing, error detection 
and recovery, flow control, and expedited data transfer. 

Class 2 service, which provides for data transfer with segmenting and flow 
control, may be satisfactory for sensors with over-sampled or perishable 
data. For voice transfers. Class 2 should also be adequate since humans can 
compensate for minor transmission errors. Offering two classes of service at 
this layer may, however, may be more inefficient than only offering the more 
reliable Class 4 service due to the greater software complexity of offering 
two classes of service. The Class 4 service proposed by NBS may be more 
suitable as it supports both connectionless and connection-oriented Transport 
service. The current development of NBS standards for the Transport Layer 
should be followed for possible application to the Space Station. 

The session, presentation and application layers support both connection and 
connectionless service in order to provide uniform service across these layers. 


5-37 



A connection-oriented session layer allow for preallocation of buffers. If 
the buffers are not available the transfer can be suspended at these higher 
layers. A connection— oriented transport layer provides the essential error 
control and sequencing and also provides a higher throughput by allowing a 
connectionless network and data link layer. 

3 . 8 Back-End Interfaces 

How are devices attached to the NIU or SDP (Subsystem Data Processor)? 

There are many standard external interfaces, parallel and serial, currently 
available. The interface alternatives include: 

Parallel Interfaces 

NTDS, Navy Tactical Data System 

IEEE - 488, General Purpose Interface Bus 

Serial Interfaces 

RS— 232 
RS-422 

MIL— STD— 1553 B 
MIL— STD— 1773 

MIL— STD— 1773 (Additions) 

Other Commercial/Spacelab 

(CAMAC External Interfaces) 

IEEE-595 
EUR— 6 100 

IEEE-596 

EUR-4600 

IEEE-683 
EUR— 4100 
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CAMAC is Computer Automatic Measurement and Control 

The above alternatives for back-end interfaces are characterized in Table 5. 

The advantages and disadvantages of each are summarized in Table A- 7 in 
Appendix A of this study. The Spacelab set is not tabulated in the table but 
are obvious candidates particularly for payload customers. 

The NTDS interface is used in many naval systems. This interface protocol 
requires a large amount of overhead with handshaking after each word. Because 
it is tailored to navy tactical devices requires large bundles of wire, and 
has high overhead, this interface should not be used on the Space Station. 


1 he IEEE— 488 interface is widely used with commercial test equipment. 
Asynchronous transfer is allowed with handshaking after each byte. Because of 
its wide use and relatively high data rate (8 Mbps), this interface could be 
used on Space Station but a serial interface would provide the same 
capabilities over longer distances with less wire and less overhead. 

Of the serial interfaces, RS232 and RS422 are used to allow interconnection of 
terminals, computers and peripherals to telecommunications equipment. These 
interfaces have limited length and require multiple lines. RS232 also has low 
data rates . 

1 he MIL— S I D— 1553B , on the other hand, operates at 1 Mbps, has no specified 
maximum length (determined by cable length, number of terminals and number of 
stubs), and uses only one wire. This is a military standard used for avionics 
systems and supported by commercial vendors. It is well defined and should be 
able to accommodate a large number of sensors and effectors as well as 
standard data processors, etc... that will be used on Space Station. A 15S3 
like interface is currently in use on the Shuttle (MIA). 

MIL— STD— 1773 (planned release date end of 1985) specifies the fiber optic 
version of MIL-STD-1553 . This interface could also be utilized on Space 
Station, but the 1773 provides no benefit over the 1553B interface. 
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Figure 6: CCSDS and ISO/OSI 
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Additions to the 1773 standard are currently being developed which would 
encompass a dual speed standard, 1 Mbps for control and 10 Mbps or 20 Mbps for 
data transfer. The development of these additions should be followed for 
possible use on Space Station. 

The Spacelab CAMAC interfaces of Table 5 represent the best example of current 
technology interfaces that have been used and are available for potential 
payload use on the Space Station. 

The development of the Langley Mesh and the SAE/AE-9B network should be 
followed and perhaps re-evaluated for possible application to the Space 
Station Program. 

It is recommended that voice and video not be integrated with data on the data 
network. The cost and complexity of the hardware components currently 
available prohibits a completely integrated system. However, as this 
technology develops, it should be further investigated. 

The Network Interface Unit (NIU) shall provide standard communications 
functions at IOC. Two options for configuring the NIU were identified. One 
option is ISO/OSI layers 1-4, residing in the NIU, and ISO/OSI layers 5-7, 
which are application dependent, resident in the host, thereby allowing the 
NIU software/hardware to be standardized. Another option is to have seven 
layers in the NIU, Layers 1-6 and Layer 7 CASE. This option provides 
flexibility in growth since a minimum amount of software would be ported to 
heterogenous processors. Further study is required in this area to determine 
the optimum configuration. 

As a result of this LAN study, there is no evidence that, once interface 
standards are established, custom interfaces for payloads could not be allowed 
if the existing standards are met. 

Connectionless service should be provided at the network and data link 
layers. At the transport layers, connection-oriented service should be 
provided. The upper layers should support both types of service. As the need 
arises, the software services in the NIU can be modified and expanded. This 
allows for reliable, efficient data transfer. 
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The MIL-STD-1553B serial interface is recommended for use on the Space Station 
for the back-end interface to the IMIU/SDP where long distances are required. 
This interface will provide 1 Mbps data transfer over a single serial 
channel. It is a military standard and is widely used in avionics systems. 

If desired, MIL-STD-1773 could be used. 

The IEEE-488 parallel interfaces also provides an alternative for a non-serial 
interface to the NIU . 

Th, interface set. used in Spacelab (Table 5) are also available candidates 
for Space Station. 


It is recommended that the Space Station onboard LAW conform to the ISO/OSI 
model. Telemetry packets (CCSDS) shall be transferred through the onboard 
local area network in the same manner as other data. 
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3 . 9 Protocols and End-to-End Compatibility 


Telemetry should follow the CCSDS standards (See Standards Option Paper). 

These standards specify a CCSDS telemetry frame. 

The telemetry packet shall be formatted in the host machine. An ISO/OSI layer 
7 process which forms telemetry packets shall be invoked by telemetry 
messages. The telemetry packets will then appear as data to the network 
ISO/OSI layers 1-6. (See Figure 6) 

At the communications gateway the ISO/OSI headers (1-6) shall be stripped off 
and the telemetry packets shall then be formatted into telemetry frames for 
transfer to the ground . 

4 . 0 Conclusions, Recommendations & Remaining Issues 

Multiple local area networks interconnected by bridges/gateways is the most 
suitable configuration for the Space Station onboard network. This provides a 
highly reconf igurable system which would potentially handle more data. The 
multiple networks should all conform to the same standard at IOC, but multiple 
standards should be allowed beyond IOC for technology insertion. 

Of the systems currently defined, the ANSI X3T9.5 Fiber Data Distributed 
Interface (Token Ring) best satisfies the Space Station requirements for 
performance, reliability/fault tolerance, and standardization. This system 
has a high growth/technology insertion potential. The cost and risk 
associated with the ANSI X3T9.5 FDDI should be relatively low since this is a 
proposed standard . 
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APPENDIX A: DECISION MATRICES 


This appendix provides a set of decision matrices comparing the alternatives 
for configurating a local area network. 

A-l Configuration 
A-2 Standards 

A— 3 Topology and Media Access Method 

A— 4 Voice/Video 

A— 5 NIU Layers 

A— 6 Connection Mode 

A— 7 Back-End Interfaces 



Table A1 : Decision Matrix: LAN Configuration 
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Table A-2: Decision Matrix: LAN-Standards 
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Table A- 3: Decision Matrix: LAN Topology and Media Access Methods 
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Table A-4: Decision Matrix: LAN - Voice and Video Integration 
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Table A-5: Decision Matrix: LAN-NIU Layers 
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Table A- 6: Decision Matrix: LAN-Connection Mode 
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Table A-7: Decision Matrix: Back-End Interfaces 
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APPENDIX B 


LOCAL AREA NETWORK ANALYSIS 


FDOI Token Ring 

Performance results for the PAWS FDDI token ring simulation model are shown 
below. Figure 8.1 represents the throughput and response time performance 
results for 5 active stations, generating all high priority messages. For this 
particular model, since all messages have top priority, message transmission is 
dependent only upon arrival of the token at a station - no token rotation time 
constraint Is applied. However, only one message Is transmitted for each token 
arrival, thus limiting each station's transmission time as well as the token 
rotation time around the ring to other stations. Input rates shown are mean 
values based on an exponential random process. The response time given is the 
time a message waits at the top of Its source queue until It Is transmitted 
onto the ring. The results show that for top priority, a higher throughput 

performance Is reached with larger data fields, however, response times are 

also Increased, 



Figure B.l PAWS FDDI Token Ring Model Performance Results - Scenario 1 
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ORIGINAL PA'iii- ai> 

OF POOR QUALITY 

Figure B.2 Involves 5 active stations, all sending 3 priority levels of data 
with Information field lengths of 1000 bytes. All priority 1 messages from one 
station are transmitted upon receipt of the token. Priority 2 and 3 message 
transmissions are dependent upon the token rotation time -or the present data 
load. Service time Is defined as a message's total queue time at a station 
before transmission. This shows that, for low ring traffic (under 100 Mbps 
total Input rate), throughput and response performances are very desirable. 
However, as the total attempted input rate exceeds 150 Mbps, ring utilization 
Is overtaken by all priority 1 messages. 



Figure B.2 PAWS FODI Token Ring Model Performance Results - Scenario 2 
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Fiber Optic Demonstration System 

Figure B.3 shows the performance results for the PAWS FOOS simulation model. 
The model contained 5 active stations with polsson Input rates and varying 
Information lengths for messages. This shows that performance of the FODS and 
FODI token ring configurations are relatively close. Again, larger data 
lengths receive higher throughput and response times. 



Figure B.3 PAWS FODS Model Performance Results 
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Token Ring 


Calibration curves for the RESQ simulation model of the token ring are shown 
below In figure B.4. The two curves represent simulation and analytical 
results. The results show that ring utilization peaks at approximately 50% and 
transfer time Is relatively low until 45% utilization where It has significant 
Increase, 



o 46 byte data packets 
o 21 byte header 
o 3 byte token 
o 10 Mbps bandwidth 
o 12 Km total ring length 
o 5 usec/Km propogation delay 
o 1.5 bit delay per node 
o 3 byte delay per message 
o 10 nodes 

o All nodes have equal priority 
o Non-redundant configuration 
o No transmission errors 


# Carrier Sense Multiple Access with Collision Detection (CSMA/CD) 

Figure B.5, shown below, are simulation and analytical results for the RESQ 
CSMA/CD simulation model. The two calibration curves give a maximum 
utilization of only 20% and low transfer time up to approximately 18% 
utilization. Overall, this architecture shows poor performance. 



46 byte data packets 

38 byte overhead 

3.47 Km effective cable length 

10 Mbps bandwidth 

5 usec/Km propogation delay between nodes 
100 nodes 

All nodes have equal priority 
96 byte interframe spacing 
168 usee delay for retry 
Non-redundant configuration 
No transmission errors 
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VI. DISTRIBUTED OPERATING SYSTEM 
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DISTRIBUTED OPERATING SYSTEM TRADE STUDY 


1.0 INTRODUCTION 


This paper presents the results of a trade study of possible functions of the 
Space Station Onboard Distributed Operating System (DOS). 

1 . 1 BACKGROUND 

The Space Station DOS is responsible for the management of functions unique to 
a collection of devices connected together through a local area network (LAN) 
or by a collection of such networks. The DOS will support the autonomous 
operation of the onboard data management system (DMS) by providing network 
transparency . Operators, customers, and application processes alike 
(henceforth collectively referred to as "user") will be able to look upon the 
network of many resources as a single entity. DOS will allow users to 
communicate with other processes in the network through the use of a layered 
communications protocol. The DOS must provide these functions with high 
performance, user friendliness, and evolutionary growth capability, all at low 
costs. Any function, such as memory management or task management, normally 
associated with the operating system within a single processor is not 
addressed in this trade study. 

1 . 2 ISSUES 


This trade study is based upon the results of the task 2 (options 
characterization) report on distributed operating systems. As identified in 
that report, the issues of concern in designing an onboard DOS are: 

1. The management of peripheral resources such as output devices and 
f’ 1 ® systems 

2. The management of memory configurations/loads in processors 
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3. The mechanism by which a user accesses a remote resource, whether to 
obtain data or to initiate an interactive session with another process 

4. The method of obtaining frequently required data • 

5. The network communication protocol 

6. The implementation of functions associated with a network 
communication protocol, such as addressing, congestion control, and 
flow control 

7. The determination of whether a given DOS function should be 
centralized, partially distributed, or fully distributed 

8. The determination of whether a given communication protocol function 
should be performed in a host subsystem data processor (SOP) or in a 
network interface unit (NIU) 

9. Additional issues include monitoring the network for performance and 
errors, maintaining a record of network transactions, network 
reconfiguration, scheduling commands and functions, and the 
verification of commands. 

While all the above-mentioned functions are necessary components of the final 
system, not all are trade study issues. Issues 2, 3, 4, and 6 are considered 
in this report, issue 8 is addressed in the Onboard Local Area Network trade 
study, and file management (issue 1) is considered in the Data Management 
System trade study. The remaining issues will be addressed by the system 
definition process (Task 4). 

This trade study is concerned only with individual functions and options. Any 
determination of whether a given function should be considered as part of the 
DOS or whether it should be an independent application program to be used by 
the DOS is left to the System Definition process. 
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1.3 TRADE STUDY CRITERIA 


The following criteria will be used to evaluate options for each of the trade 
study issues: 

GENERIC ISSUES (common to all trade studies) 

1. Cost 

o Development 

o Life cycle 

2. Risk 

o Development 

o Production 

o Technology readiness 

3 . Performance 

o CPU Utilization 

o Memory Utilization 

o Speed 

4. Standardization/Commonality 

5. Growth/Technology Insertion Potential 
TRADE STUDY UNIQUE ISSUES 

1. Extent of benefit to a customer 

2. Extent of benefit to an operator 

3. Extent of benefit to an application programmer 

4. Reliability/Availability 

5. Maintainability (ease of modification) 

6. Effect on network traffic 
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1.4 APPLICABLE OPTION PAPERS: 


0 

1.7. 1.2. 

Network Interface Unit 

o 

2.1.1 

Data Base Management 

o 

2.1.3 

Distributed Operating System 

o 

2.2.3 

System Growth 

0 

2.3 

System Security/Privacy 

0 

2.4 

Time Management 

0 

2.5.2 

Local/Remote Area Communication 

0 

2.5.3 

Local Area Network Systems 


Of the papers, 2.1.3, 1.7. 1.2, and 2.5.3 are the most applicable to this trade 
study . 

1 . 5 ALTERNATIVES 

This section will summarize the results of the distributed operating system 
options paper by introducing each trade study item and options for same. 

(1) Method of Accessing Remote Processes and Data 

- Should there be multiple methods by which remote data or 
resources may be obtained? 

Options: - All remote resources and data are accessed only through 

interprocess communication 

- Have special access schemes for frequently accessed data 

- Method of Obtaining Frequently Required Data of Remote Origin 

Applicable only if the second option is selected above 

Options: - Centralized database of commonly accessed data 

- Broadcast of commonly accessed data 

- Multicast of commonly accessed data 
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(2) Addressing 


- How do applications specify the address of a process with which 
they wish to communicate? 

Options: — Flat Addressing (Specify only the name of the process) 

- Hierarchical Addressing (address by specifying Net. 

[Host or Functions] Process) 

- How should address tables be distributed? 

Options: - Centralized 

- Fully Distributed 

- Partially Distributed 

- If the partially distributed option is chosen, how should 
unknown addresses be obtained? 

Options: - From a centralized name server 

- Through broadcasting a request for the address 

- Through a centralized name server, but with the ability 
to broadcast a request for the address as a backup 

(3) Management of Memory Configuration/Loads in Processors 


What is the extent of automated reconf iguration of memory loads in 
processors? 

Options: - Automatic load a spare processor in the event of failure in 

the active processor. 

- Automatically replace less critical memory loads with 
higher priority loads when necessary. 


6-7 



(4) Presentation Layer Services 


Which services are needed onboard at IOC? 

Options: - Data Encryption 

- Data Compression 

- Character Code Conversion 

- Graphics Conversion Protocols 

(5) Network Protocol Functions 
(A) Packet Sizes 

- Sizes of packets within the network 

Options: - Fixed Length 

- Variable Length 


(B) Routing 

— Should routing tables be dynamically reconf igurable? 

Options: - Static Routing 

- Dynamic Routing 

- Distribution of Routing Tables 

Options: - Located in all NIUs 

- Located at Gateways/Bridges only 
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(C) Congestion Control 


- What is to be done to prevent or handle congestion? 
(congestion is the result of an NIU's buffering capacity 
being overrun through incoming messages from several 
sources) 

Options: - Buffer Allocation and Packet Discard 

- Choke Packets with Packet Discard as a Backup 

- Connection-Oriented Service Within the Network 

(D) Flow Control 

- What is the method of preventing a transmitting NIU, Host, 
or Process from overrunning the receiving capability of 
another NIU, Host, or Process? 

- At Layer 2 (Flow control between individual NIUs) 

Options: - Discard Packets 

- Limit Number of Transmissions Per Unit Time 

- At Layer 3 (Flow control between source and destination NIUs) 

Options: - Sliding Window 

- Discard Packets 

- At Layer 4 (Flow control between source and destination SDPs) 

Options: - Credit Window 

- Discard Packets 


6-9 



2.0 METHODOLOGY 


This trade study incorporates the results of the Distributed Operating System, 
Network Interface Unit, and Local Area Network Task 2 Option Papers in 
determining the major issues to be resolved in defining the Space Station 
Onboard Distributed Operating System and the alternatives for each such 
issue. Additional information not covered by the Task 2 reports have been 
incorporated from references 1 and 2 and will be addressed in the task 4 
Preliminary System Definition Report. 

Each of the alternatives for a given trade study issue were carefully 
evaluated in order to determine their advantages and disadvantages. These 
advantages and disadvantages were established as a result of the team 
experience base at IBM in the area of operating systems, interviews with 
experts, and through literature surveys. 

The advantages and disadvantages were then evaluated in terms of the trade 
study criteria in order to arrive at prioritized options for each issue. The 
weighting for each criteria was determined in accordance with the issue under 
consideration. The results of this trade study are presented below in section 

3.0 and summarized as a set of decision matrices in Appendix A. 

3.0 RESULTS 

This section will present the results of the trade study of each of the trade 
study issues. For convenience, each of the issues is listed below. 

1. Method of accessing remote processes and data 

2. Addressing 

3- Management of memory configurations/loads in processors 

4. Presentation Layer Services 

5. Network Protocol Functions 
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3.1 METHOD OF ACCESSING REMOTE PROCESSES AND DATA 


Due to the need for accessing remote resources such as databases and file 
servers, it is accepted that some type of Request/Wait/Receive interprocess 
communication (IPC) facility will be required as part of the DOS. The trade 
issue arises when remote data is considered. Such data may be a sensor value 
or value of a variable, for example. For the remainder of this section, it is 
assumed that application programs will request data or access to a remote 
resource through a set of procedures provided by the DOS. The DOS in turn 
determines the actual method of accessing the data or resource. 

If the IPC facility is used for accessing all remote objects, be they 
resources or data, much bandwidth will be utilized in the form of messages 
between requestors of data and owners of same. For data which is accessed on 
a frequent basis by several applications, the message traffic can comprise a 
significant portion of network traffic. In addition to effects on traffic, 
another adverse effect of IPC is the burden placed on owners of data to answer 
requests . 

In order to overcome these disadvantages of IPC, other means of accessing 
frequently required data were considered. While alternatives exist which 
could eliminate the need for IPC between a requestor and the owner of data, 
such techniques have disadvantages in making the DOS more complex and being 
less reliable than direct IPC between the processes involved. The trade of 
whether or not to have an alternative means of obtaining frequently accessed 
data is summarized in Figure 1. The results were an alternative method of 
obtaining frequently required data. 

ALTERNATIVES METHODS FOR DELIVERING FREQUENTLY ACCESSED DATA 

As the trade study revealed, an alternative method of delivering frequently 
accessed data would indeed be beneficial, and alternatives in turn had to be 
traded. Three options were found: (1) owners of frequently accessed data 
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TOTAL AND COMMENTS 1,000 825 910 - FOR DATA WHICH IS ACCESSED 

FREQUENTLY BY MANY SOURCES 



transmit the values to a central database, (2) data owners of broadcast values 
on a periodic basis, and (3) owners of data multicast values, also on a 
periodic basis. 

Centralized Database of Values 

Of the three options, transmitting values to a database has the least promise 
of reducing network traffic. Instead of sending requests to the owners of 
data, all applications requiring a given value will have to request the 
database manager for the data. The only possibility of reducing message 
traffic arises if several values are required by each application. In that 
case, a single request to the database can return several values at once. The 
database approach does offload owners of data from the need to answer requests 
for the data. In addition, the cost of development of the database is not a 
factor since a database will exist anyway for the purpose of achiving values. 
In addition to a large contribution to network traffic, accessing from the 
database will be comparatively slower than either broadcast or multicast. 

Broadcast of Values 

The second option is to have owners of data broadcast values on a periodic 
basis. The effect of broadcast on message traffic is dependent on the 
configuration of the onboard LAW, the number of applications which require a 
particular data value and the location of these applications in terms of the 
configuration . 

If the onboard configuration consists of a single LAW or two LAWs (i.e., one 
for core functions and one for payload functions), a broadcast will involve 
only two messages at most. If multiple LAWs are utilized, such as a LAW in 
every module, the message overhead increases. However, if many applications 
require a value, and further, if these applications are distributed throughout 
the individual LAWs, the message overhead increase of broadcast is negligible. 
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A disadvantage of broadcast is that if a given value is required by only 
a small number of applications when compared with the total number of 
applications onboard the SS, each NIU will have to read in the message and 
look at the contents in order to determine if the value contained within is 
required by applications running in the NIU or in an attached SDP. If the 
number of broadcast values is large, this can result in an unacceptable amount 
of overhead . 

One way in which this potentially serious overhead may be overcome is to 
indicate the contents of the message in a special header field. This approach 
violates the International Standards Organization (ISO) Reference Model of 
Open Systems Interconnection (OSI) (References 3-4) by placing information 
regarding the contents of the message in the Layer 2 (Data Link Layer) 
header. Further, such a scheme may be difficult to implement and maintain as 
the special field will have to be read and interpreted by the NIU interface 
with the physical medium. 

Multicast of Values 

The third scheme is multicast of values by the source. This technique 
eliminates the disadvantage of broadcast in that a message is specifically 
addressed to only those who need it. The disadvantages of multicast arise in 
maintaining the list of destinations and in actually indicating all the 
destinations in a limited length address field. The latter problem may be 
resolved by allowed addresses to be placed in the data field. This is 
particularly feasible as commonly accessed data will occupy only a few bytes 
of the data field, leaving much room for addresses. 

The results of the trades in this area are summarized in Figure 2. It appears 
as if accessing data from a centralized database may be the best choice, 
although the bottom line scoring is close for all alternatives. However, it 
must be kept in mind that the trade study was performed without the benefit of 
actual data concerning the number of applications involved, estimated network 
traffic, etc. The actual choice between the options is therefore left until 
such data may be available. 
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DECISION ITEM: ACCESS METHOD FOR COMMONLY REQUESTED DATA 
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Figure 2. Access Method for Commonly Requested Data 



DECISION ITEM: ACCESS METHOD FOR COMMONLY REQUESTED DATA (CONT'D) 
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Figure 2 (cont’d) 



3.2 ADDRESSING 


This category of trade study issues involves three such issues: (a) The method 
of addressing employed by application programs, (b) Whether address tables 
should be centralized, fully distributed, or partially distributed, and (c) 
What is the means of obtaining an unknown address if partially distributed 
addressing is utilized. 

METHOD OF ADDRESSING BY APPLICATIONS 

Two options for addressing by applications were identified. The first is flat 
addressing, which provides network transparency by requiring the application 
to specify only the logical name of the process with which it wishes to 
communicate or the logical name of the sensor or variable whose value is to be 
accessed. The second technique is hierarchical addressing, where the 
application specifies a logical path to the desired resource. This path may 
be specified by NETWORK - [HOST or FUNCTIONS] - [PROCESS, SENSOR, OR VARIABLE] 
where function refers to ECLS), N&C, etc. The term HOST is proved as an 
alternative since a given process may not be part of a well known function 
(e.g., payloads). In both schemes, the DOS assumes the responsibility for 
mapping the logical address onto a physical one. 

The advantage of flat addressing is network transparency in the eye of the 
application programmer. The disadvantages include the need to maintain 
globally unique names for a large number of processes, sensors, etc. and the 
need for larger address tables. Hierarchical addressing makes it easier for 
the DOS to determine a physical address to the desired resource and eliminates 
the need for globally unique names. However, the network is no longer 
transparent to the application programmer. The results of the trade study of 
this issue is summarized in Figure 3. Once again, both options appear to be 
equally good choices. 
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DECISION ITEM: ADDRESSING METHOD 
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DISTRIBUTION OF ADDRESS TABLES 


There are three options for the distribution of address tables: a centralized 

name server, fully distributed tables, or partially distributed tables. . 

A centralized name server saves memory space in individual NIUs (assuming 
addressing is performed in the NIUs) and makes maintenance of address tables 
much easier. However, performance penalties include time expended in 
obtaining an address and the resulting increase in network traffic as all NIUs 
must access addresses from this centralized location. An additional 
disadvantage is the cost of the SDP or NIU which is to function as the name 
server and the backups (for fault tolerance) of same. 


A fully distributed address table means that all addresses of all sensors, 
variables, processes, networks, hosts, etc. are stored in every NIU. This can 
mean an enormous amount of overhead in terms of memory utilization. In such a 
scheme, address updates will be very costly in terms of the network traffic 
(update packets and acknowledgements), albeit such updates will not occur 
often. A fully distributed address table presents a great advantage access 
speed . 

A partially distributed address table is one where each NIU maintains only 
those addresses which it requires. For the general case, this represents the 
optimal use of memory to obtain the best access speeds. However, having 
partially distributed address tables brings the question "What is to be done 
if the local table does not contain a necessary address?". The answers to 
this question are the options of the next issue to be resolved. 

The trade study of the issue "How should address tables be distributed?" is 
summarized in Figure 4. The results of this trade indicate that a partially 
distributed address table is the best choice. 
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DECISION ITEM: DISTRIBUTION OF ADDRESS TABLES 
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EFFECT ON NETWORK TRAFFIC 200 50 - HEAVY TRAFFIC 200 - 170 - OCCASIONALLY 

TO CENTRALIZED AFFECTS NETWORK 

LOCATION TRAFFIC 

TOTAL AND COMMENTS 1,000 685 785 835 



METHOD OF ACCESSING AN UNKNOWN ADDRESS 


This issue is applicable only if a partially distributed approach is chosen 
for address tables. The alternatives for accessing unknown addresses include 
maintaining a centralized name server and broadcasting a request for a desired 
address. A third alternative is a hybrid a centralized name server scheme 
with the ability to broadcast as a backup. 

The centralized name server has advantages of guaranteed access to the 
address, has potentially less traffic overhead, and is potentially faster than 
broadcasting for the address. Disadvantages include the cost of the name 
server(s), high memory usage by the name server, the need to keep the name 
server up to date, and the remote possibility that the name server(s) could 
fail . 

Broadcasting a request for the address eliminates the need for an all-knowing 
central name server, but is potentially much slower than accessing an address 
from a name server. In addition, the formerly mentioned problems of burden on 
every NIU to read the message and the message traffic associated with a 
broadcast apply. In addition, since broadcasts are generally not 
acknowledged, there is no guarantee that the NIU which knows the requested 
address ever receives the request or that any reply will reach the requestor. 

The hybrid approach is: (1) first attempt to access from a centralized name 
server, and if it is not available, (2) then a broadcast request for the 
address may be sent. The results of the trade study are shown in Figure 5. 

For this issue, a centralized name server or a centralized name server with 
broadcast as a backup technique seems appropriate. The former will be cheaper 
to develop, while the latter provides more fault tolerance. 

3.3 MANAGEMENT OF MEMORY CONFIGURATION LOADS IN PROCESSORS 

This topic was not addressed in the options study. An extended discussion of 
the issues is therefore provided. 
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DECISION ITEM: ACCESSING UNKNOWN ADDRESSES (IF PARTIALLY DISTRIBUTED ADDRESS TABLES) 
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The management of the configuration of application tasks both within a single 
processor and among the resources of the network is a problem which presents 
several opportunities for automation. From the time that application tasks 
are initially loaded into the processors of the network, failures, 
maintenance, and even entering different phases of Space Station operation may 
require reconf iguration of tasks among resources. The most critical need for 
an automated reconf iguration facility is in managing redundant computers. 
Failures in computers running time-critical applications require that the 
switch to a backup be automatic as the applications running in the computer 
may not withstand the delay associated with crew or ground controlled 
reconf iguration . 

Other situations requiring reconf iguration involve the loading of software 
either into idle spare machines or into machines in which applications already 
reside. Such situations may arise as a result of failures in processors with 
no backups or just in the course of time. An example of the later is the use 
of maintenance expert system by a crew member. Since expert systems are 
expensive in their use of resources, it is conceivable better to load the 
expert system software into a processor only when it is to be used. The 
decision of where to load the software may be made by the crew member or by 
the DOS. It is important to note that any reconf iguration of applications 
among processors is meaningful only if the applications have access to 
necessary sensors and effectors. 

Assuming that the Space Station architecture allocates a pool of processors as 
spares, it appears feasible that the DOS be capable of assigning and loading 
software from mass memory into such a spare processor as necessary, problems 
arise when all available resources are being utilized. 


One architectural option is to have fixed memory configurations. The 
configurations will allocate certain locations in memory for DOS and other 
system software. The remaining locations in memory will be used by 
application tasks. Since all processors will contain certain systems 
software, the term memory configuration will henceforth refer to groups of 
applications tasks to be loaded into a processor at once, with no possibility 
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of dividing individual tasks among different processors. Such configurations 
may be amended by an overlay, where a second set of application software 
(second configuration) replaces the already resident configuration. If a new 
configuration must be loaded into a processor, a full replacement of preloaded 
application tasks is necessary. The task of deciding which configuration is 
more important in a given situation may be automated by use of an expert 
system or by other means such as priority tables. 

The second architectural option is to allow tasks to be dynamically loaded 
into processors. This option provides a better solution to the problem of 
fault tolerance (e.g., more flexible) and also has the potential for making 
better use of available resources than the fixed memory configuration scheme. 
With this option, if all processors are being utilized and there is a need to 
load a new task, then a decision must be to either to (a) find a processor 
which is capable of assimilating the new task without adversely affecting 
already resident software, or (b) to partially or fully replace the resident 
software. These schemes require an algorithm to determine where a task may be 

moved to, the ability to assign a priority to that task in its new 

environment, and a dynamic linking capability. A dynamic task transfer 
capability will make verification more difficult since the possible 
combination of tasks within a processor will not be predictable. The final 
drawback of task migration is the potential inability to meet timing and 
jitter requirements due to interference between tasks. 

In summary, the results of this trade indicate that the management of the 
configuration of application tasks amont network processors will be partially 
automated. Certainly, the need to automatically switch to backup computers is 

a necessity since time critical functions may be involved. The choice of a 

spare computer into which new software is to be loaded is also recommended for 
automatation . The only decision left open is the case when all processors are 
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being utilized and new software must be loaded. The extent of automation is 
dependant on the architecture which is chosen. The results of this trade 
study will be combined with that of potential architectures to determine this 
extent of automation. Currently, it appears that the fixed memory 
configuration scheme will be the choice of architecture . If this choice 
holds, it would mean that an automated decision making capability could be 
used to reconfigure the loading processors even when all processors are being 
utilized. Of course, a crew or ground override capability must be implemented 
to allow manual control in situations where it may be necessary. 

3.4 PRESENTATION LAYER FUNCTIONS 

The purpose of this trade is to assess which Presentation Layer (6) functions 
(if any) will be required onboard the Space Station at IOC. The functions 
under question include (1) data encryption, (2) data compression, (3) 
character code conversion, and (4) graphics conversion protocols. 

The potential need for the functions listed above is based on the requirements 
stated in the Space Station Request for Proposal (RFP) (Reference 5). It is 
indicated that data encryption is to be provided by the DMS (Paragraph C-3 
3.1-D). Further, the need to handle very large amounts of data suggest that 
data compression could be very useful at IOC. 

The need for functions 3 and 4 is not clear. The RFP (Paragraphs 2.1.5 and 
2.2.5.3-G) indicates that common hardware and software will be employed as 
much as possible. Functions 3 and 4 are used explicitly for converting 
between non-standard formats. For this reason, functions 3 and 4 have been 
chosen as growth items, assuming that the requirements for commonality are 
relaxed in time. There may be a need, however, to translate between possibly 
incompatible formats employed in onboard and ground systems. For these 
situations, it would be much more cost effective to perform such conversions 
on the ground. The results of this study are summarized by the fifth decision 
matrix in the appendix section. 


6-25 



3.5 NETWORK PROTOCOL FUNCTIONS 


The final area of trade study issues falls under the classification of network 
protocol functions. These issues, packet sizes, routing, congestion control, 
and flow control, are part of every network protocol implementation. Another 
network protocol function, addressing, has been discussed separately. Unlike 
the other trade study issues, it is difficult to perform studies on functions 
such as routing, congestion control, and flow control without knowledge of 
network traffic conditions and the needs of the application programs. For 
this reason, an attempt will not be made to select a single implementation 
technique for each function, but rather, suggestions will be made as to which 
of the options may be appropriate. 

PACKET SIZES 

The issue related to packet sizes is whether to have fixed length or variable 
length packets in the network. Fixed length packets make development and 
maintenance easier, but may waste bandwidth and be unfair. If the fixed 
length is too high, small messages such as sensor values will waste most of 
the packet bandwidth. If the packet length is chosen to be too small, then 
long messages, such as file transfers, will have to be broken into many 
packets, resulting in longer delivery times as packets wait to get media 
access. Variable length packets make better use of available bandwidth and 
can be more fair. 

However, having variable length packets will make initial development costs 
higher. For reasons of growth capability and better utilization of bandwidth, 
variable length packets are suggested. 

The maximum packet size will be determined once more is known about the 
overall network traffic. At present a preliminary value of 2048 Bytes has 
been chosen. 
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ROUTING 


Once a destination address is determined, it is up to the routing function to 
determine the physical path which should be taken in order to eventually reach 
the destination. In a single ring or bus configured LAN, an address 
specifying "NIU_HOST_PROCESS" is sufficient for reaching the final destination 
as the NIU for which the packet is addressed simply picks it up. However, 
when a packet is addressed to a destination in another network, (e.g., 
NET_NIU_HOST_PROCESS) , a routing table must be consulted in order to determine 
the path to reach the destination network. The trade issues associated with 
routing include (a) static vs. dynamic routing tables (reference 4) and (b) 
the distribution of routing tables. 

Static routing tables are those which are determined and loaded into the 
appropriate NIUs or SDPs before the network is activated. Such a table does 
not change thereafter until an alternative routing table is once again 
explicitly loaded (e.g. when reconf iguration occurs). These tables have the 
advantage of simplicity and can provide good performance. In addition, it is 
possible to construct static routing tables in such a way that alternative 
routes can still be utilized. However, static routing tables are not 
adaptable with respect to changing network traffic conditions and 
configuration . 

Dynamic routing tables have the advantage of being adaptive, but require a 
more complex DOS and may also cause an increase in network message traffic. 
Routing tables may be reconfigured locally or by centralized server. Numerous 
schemes exist by which dynamic routing algorithms may be implemented. 

Based on the probable ring or bus-connected LAN configuration of Space 
Station, the need for routing will be very limited (i.e., routing tables are 
necessary only for determining paths between networks). Since the number of 
such networks will be small and will not change often, a static routing table 
will be sufficient for the needs of SS. 
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Distribution of Routing Tables 


This issue is the placement of the static tables within the Space Station 
network of individual LANs. Since routing is necessary to determine the path 
from one network to another, routing tables should be maintained in every 
bridge. The remaining question is whether or not routing tables need to be 
maintained in every NIU. 

Consider a LAN with only one bridge. In such a LAN, if an NIU encounters a 
need to transmit a packet to another network, it may simply forward the 
message to the bridge, which then looks up the route to the final destination 
and forwards the packet. In a LAN with more than one bridge, a particular 
bridge may be designated to forward all inter — network messages. The other 
alternative is maintain a routing table in each NIU, so that the load in the 
bridges is more evenly distributed. 

Since the size of the routing table will be small, placing the routing table 
in every NIU will not be extremely wasteful of memory. For this reason, the 
choice of whether to place routing tables in every NIU of a LAN with multiple 
bridges is left as a design decision. 

CONGESTION CONTROL 


Congestion is the result of a given NIU's buffer space being overrun by 
incoming transmissions from several sources. Various schemes exist for 
implementing congestion control (reference 4) including (a) allocating buffers 
to incoming packets by the packet's priority, number of hops traversed by the 
packet (seniority), or an a FIFO basis and then simply dropping packets as 
buffer space is exhausted, (b) by monitoring the traffic on incoming lines and 
as congestion appears likely, sending a message to the sources of the packets 
requesting a reduction in the number of packets being transmitted, and (c) by 
using connection-oriented service within the network, which prevents 
congestion by preallocating buffer space for each message. 
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The trade in this area is based on the assumption that congestion will occur 
infrequently due to the careful design of the network (i.e. sufficient network 
bandwidth, etc.)- With that assumption, connection-oriented service (at Layer 
4) is suggested for long messages (such as file transfers) while the buffer 
discard algorithm may be sufficient for small messages. Mote that the latter 
scheme requires that end-to-end acknowledgements be utilized. Otherwise, 
there is no guarantee that a given packet reaches its destination. The choke 
packet scheme will be useful if congestion is likely to occur frequently and 
in general, messages are sufficiently long that the source may be requested to 
'choke 1 its transmissions. Since congestion and long messages are not likely 
to be frequent occurrences onboard the Space Station, the choke packet scheme 
is not recommended. 

FLOW CONTROL 


Flow control is prevention of a faster NIU, host, or process from overrunning 
a destination NIU, host, or process. With this definition, flow control is a 
part of Layers 2-4 and the Layer 5/Layer 4 interface of the ISO/OSI reference 
model. This section presents options for flow control at each layer as 
obtained from reference 6. Once again, more concrete figures for expected 
traffic and better knowledge of the needs of the application processes will be 
required before effective trades can be performed. As in previous sections, 
suggestions will be made regarding the option(s) most appropriate for SS . 

Flow control at layer 2 is concerned with transmissions between NIUs. With 
the requirements for commonality onboard SS, flow control at layer 2 should 
not be necessary as a NIU will likely have matched speeds for sending and 
receiving. However, if in growth, flow control becomes necessary, the options 
are a discard packet algorithm (flow control at the destination) or to limit 
the number of packets which may be transmitted per unit of time (flow control 
at the source). If the former is employed in a ring network, very fast 
feedback can be provided to the sender by simply modifying a bit in the packet 
if it cannot be accepted. Limiting the number of transmissions out of an NIU 
may be helpful in controlling jammed NIUs, but it may be difficult to choose 
the optimal limit to provide flow control and yet not unduly restrict the 
sending NIU. For these reasons, the discard packet scheme is recommended 
instead of the transmission limit scheme. 
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Source-Destination flow control is achieved at Layer 3. At this level, 
several techniques of flow control exist. These include among others: (a) the 
sliding window scheme and (b) the discard packet scheme. The sliding window 
scheme is one way of implementing connection service at Layer 3. 

The sliding window scheme requires a small number of buffers to be allocated 
at the destination NIU, but is an effective means of flow control and 
sequencing. This scheme may be used in conjunction with connection service 
and is recommended for long messages and critical messages. 

Discarding packets is easy to implement, but at layer 3, may be considered to 
be too wasteful of bandwidth since a packet may have travelled through several 
networks in order to reach the destination. This scheme also implies that the 
packet must be acknowledged, otherwise there is no guarantee of delivery. The 
discard packet algorithm will be sufficient for messages using connectionless 
service . 

Flow control at the transport layer (layer 4) may be implemented by at least 
two techniques. One method is the credit window scheme, where before 
transmission begins, the destination host is contacted and queried as to the 
number of packets which may be accepted. This method may be utilized in 
conjunction with connection-oriented service at the transport layer. Another 
technique, to simply drop packets, may be employed for messages using 
connectionless service. 

4.0 CONCLUSIONS, RECOMMENDATIONS & REMAINING ISSUES 

This trade study has addressed several pertinant issues regarding the 
development of a Space Station Distributed Operating System (DOS). The study 
has resulted in the following recommendations: 

Data Access Method - Primarily through interprocess communication (IPC), 

with commonly acquired data being accessed through a 
centralized database, or obtained through broadcast or 
multicast . 
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Addressing 


Management of 
Memory Configura- 
tion/Loads in 
Processors 

Presentation Layer — 
Services 


Network Protocol 
Functions - 


Choice of flat vs. heirarchical addressing left as a 
design decision. Address tables should be partially 
distributed, with unknown addresses being accessed 
primarily through a centralized name server and 
through broadcasting a request for the address if the 
name server is unavailable. 


Automatic switching to backups, automated loading of 
spare processors. Automated replacement of lower 
priority loads with higher priority loads is 

a possibility if fixed memory configurations are 
utilized . 

Data encryption and data compression should be 
made available if necessary, other presentation layer 
services are null at IOC and may be added as onboard 
commonality decreases. 

Variable length packet sizes with max size = 2048 Bytes 
Static routing tables 

Decision of whether routing tables should exist 
in every NIU or only in bridges is left as a 
design issue. 

Congestion control through connection service for 
lengthy, critical, and high-priority messages. 

Congestion control for other messages through packet 
discarding . 

Flow control at layer 2 through dropping packets 
Flow control at layer 3 through dropping packets for 
connectionless service 

Flow control at layer 4 through credit window 
protocols for connection-oriented service, through 
dropping packets for connectionless service 
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A number of issues remain to be addressed in the preliminary system definition 
report. Both the Distributed Operating System options paper and trade study 
have not dealt with the question of determining which functions should be 
considered as part of the operating system and which should be considered as 
applications to be invoked by the operating system. In addition, the system 
definition report should address the question of division of labor between 
SDPs and IMIUs and any interfaces between the two. Finally, the system 
definition report should present an integrated system composed of the many 
individual functions which have been discussed in the context of this trade 
study and the options paper. 
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6.0 APPENDIX 


This appendix contains a summary of the results of the trade study in the form 
of decision matrices. The matrices list the item under consideration, options 
for the item, advantages and disadvantages for each option, choice(s) among 
the options, and rationale for the choice(s). 
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System Definition Decision Matrix: Distributed Operating System (Page 1 of 6) 
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VII. SOFTWARE CONFIGURATION MANAGEMENT 
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SOFTWARE CONFIGURATION MANAGEMENT TRADE STUDY 


1.0 INTRODUCTION 

1 . 1 BACKGROUND 

Configuration Management is the identification of the characteristics of a 
computer software system at discrete points in time for purposes of 
controlling changes and maintaining the integrity and traceability of the 
system throughout its life cycle. Configuration Management (CM) is important 
to the Space Station because it will be the mechanism for NASA to authorize 
capabilities , track progress and ensure that the software deliveries are 
cohesive. A CM system which provides the functions listed below can also be 
considered a tool used by subsystem and customer management to plan, schedule 
and track the tasks and resources assigned to them. 

There will be a large number of areas using the SSE, including application 
software developers, SSE developers, payload developers, ground support 
developers, and various test functions. In this study, the term "user group" 
will be used to define some set of users which is working on the same task and 
requires the same functions from the SSE. 

The Configuration Management system should encompass the following: 

DEFINITION OF INCREMENTAL SOFTWARE RELEASES AND CAPABILITIES. The capability 
to define software increments will be required since the Space Station itself 
will be built incrementally, and there will be periodic upgrades in technology 
and function. A way to define and record capabilities (e.g., CRs-Change 
Requests) will also be required together with a method of associating the 
capabilities with projected releases. 

CONTROL OF CAPABILITIES. The CM system must allow the user group to define 
the approval level required for updates. This will vary between user groups 
depending on the autonomy level of the subsystems involved. For example, one 
subsystem may require multiple control board approval, while a completely 
autonomous payload system would require no approval or internal approval only. 

COSTING CAPABILITIES. The CM system must provide a way to associate a cost 
with each requested update. This cost could affect the approval of the update 
and the assignment of the update to a release. 
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TRACKING MECHANISM. The Configuration Management system must allow for 
defining a consistent set of development milestones and recording of projected 
schedules and actual progress according to those milestones. The capability 
to generate reports and graphical representations of this data must also be 
provided. 

DEPENDENCY IDENTIFICATION. The system must provide a way to record 
dependencies among projected capabilities. 

COMMUNICATION. A subset of the data maintained by the Configuration 
Management system will be of interest project wide and must be made 
available. Other parts will remain strictly for the use of the subsystem 
developers and their NASA monitors. 

TMIS INTERFACE. The interface between the TMIS and the SSE Configuration 
Management functions must be defined in such a way as to minimize redundant 
data and to provide cross referencing capabilities. 

It is assumed that to maintain configuration control over the Space Station 
software, the project will utilize a series of NASA, contractor and customer 
control boards (similar to what has been used in previous NASA projects) and 
an automated data base system for storing and enforcing decisions made by the 
boards. Figure 1 is an example of how the boards may be structured. The 
boards are responsible for defining both the software increments and their 
contents. They must ensure that the scheduled contents of each increment meet 
the requirements defined for the increment. Lastly, through authorized board 
representatives , they are responsible for entering their decisions into the 
data base . 

This trade study addresses three approaches to providing the data base system 
mentioned above. Since the board structure is currently undefined and may 
change after it is initially established, the impacts of such modifications on 
each alternative will have to be considered. 



Some assumptions were required to be made prior to beginning this trade 
study. They include: 

o There will be a large number of areas using the SSE, including application 
software development, SSE development, ground support development and 
various test functions. The SSE will also be made available for payload 
application development. Me will use the term 'user group' to define some 
set of users working on the same task. It is assumed that each of the 
four primary Space Station sites may contain multiple user groups and that 
user groups may exist at other locations as well. Because of this 
assumption, this trade study will be totally independent of the trade 
study being performed on the facilities options. 

o The basic element of configuration control will be called a 'control 
instrument 1 . This generic classification would cover things such as 
Change Request (CR), Discrepancy Report (DR), Program Change Request 
(PCR), Problem Trouble Report (PTR) and any other type of document which 
might result in a software change. 

1.2 ISSUES 

There are a number of issues in the area of configuration control. Some of 
the issues are: 

1) The configuration control board structure across the project and how 
much uniqueness will be allowed at each site and within each user 
group . 

2) Whether the payload customers will be encouraged or required to use 
the SSE for their development. NASA may want to make the SSE 
available for use by all customers and would want to maintain 
configuration control over non-autonomous payload software. If this 
is the case, the easiest way to accomplish this would be to require 
the non-autonomous software to be developed in the SSE under its CM 
system. If the SSE is perceived by potential customers are being 
counter— producti ve , it could discourage them. 

3) The level of security (privacy) required among user groups on 
detailed planning and scheduling data. 
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Figure 1. Proposed Space Station Control Board Structure 
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4) Software components managed. Traditionally, requirements , design and 
source and executable code have been configuration controlled. The 
Space Station must address these plus elements of new technologies 
such as new DBMS. 

5) TMIS interface. 

1.3 TRADE STUDY CRITERIA 

Several criteria have been selected to be used in the evaluation and 
comparison of the selected Configuration Management alternatives. The 
criteria and a short description of each may be found in the following 
sections . 

1.3.1 GENERIC 

COST 

This criterion addresses the basic costs for the initial development or 
acquisition of the CM system and for maintaining and operating it for the 
duration of the project. This cost will be only that amount necessary to 
implement the functions described in "Background". Since most of the other 
criteria address attributes of the CM system which can be improved if enough 
money is invested, this basic cost comparison will not include any cost to 
make the CM system easier to use, more adaptable, etc. The cost of these 
enhancements will be considered along with the criteria which are affected. 

DEVELOPMENT TIME 

The intent here is to consider factors other than available manpower (or 
money) which may affect the amount of time required to implement the CM 
system. An example may be the amount of time necessary to define a system's 
design because of its complexity. Having more manpower available in this case 
may not decrease the total amount of time required. Under this criterion, 
commercially available systems will be given favorable scores if their 
purchase prices are less than development cost. 
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TECHNICAL RISK 

This will look at each CM system alternative and determine what attributes of 
the alternative might influence the chances of successfully implementing that 
CM system. Items considered will include the complexity of the required 
components and the current state of the technology required to build the 
system. 

IMPACT ON OTHER TOOLS 

This deals with how other tools (part of the SSE or site-specific) are 
affected by the structure of the CM database. Items considered will include 
ease of extracting data and effect on tools of changes to the database 
(especially if a change to the database can affect a site's tools even though 
the change does not directly affect the site). The impact of Configuration 
Management changes on the interface between the SSE and TMIS will also be 
considered here. 

MANAGEABILITY OF DATA 

This will assess whether a particular alternative will allow tracking (and 
enforcement) of the way the data is used at different sites. The aim here is 
to allow users from different sites to be confident that a piece of data is 
used consistently at each site. 

EASE OF USE 


This will examine the perceived ease of use of the system. The major 
viewpoint taken will be that of the users at a site, but the ability to access 
data at a site by a user from another site will also be examined. 

FLEXIBILITY 


The ability to change the definition of the CM database will be examined 
here. This will include the ease of adding, deleting, or modifying fields and 
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records in the database and the impact of database changes to the various 
sites. It is recognized that the requirements for the CM will not remain 
unchanged over the life span of the Space Station. Therefore, changes to the 
CM software will have to be made. This criterion addresses the impact to the 
users of affecting the changes. Part of the impact of installing changes will 
be the amount of time the CM system is required to be down during 
installation . 

1.3.2 TRADE STUDY UNIQUE 

AVAILABILITY OF DATA TO OUTSIDE USERS 

This will address the ease with which a user at a different location can 
access data from a particular site. Depending on the alternative being 
addressed, the data may be the actual data from the site or a summary of the 
data in a common format. Items considered will include the interface between 
sites, integration of data from different sites into reports or a central data 
base, and the interface with TMIS. 

SECURITY 

The ability of each alternative to control access to its functions and data 
will be addressed here. Among the items considered will be the ability to 
control definition (establishment) of databases and the ability to control use 
of the databases (especially updates) from the level of the entire database 
down to the field level within the database. 

USER ACCEPTANCE 

This will address the level of user acceptance anticipated for the 
alternatives. An example might be whether a particular alternative will tend 
to be looked on unfavorably because it mandates a set of controls that a given 
user group has never used in the past and does not see a good reason to use in 
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the future. This criterion is included because a CM system which is disliked 
by its users stands a good chance of not being used or of being used 
incorrectly. Either way, the CM system will not help the users produce high 
quality software in a cost-efficient manner. In fact, if the user 
dissatisfaction is great enough, the CM system could be a contributor to lower 
quality and greater costs. 

ADAPTABILITY 

This criterion will address how well the alternatives can provide a CM system 
which is adaptable to the needs of its users. A system which cannot be molded 
to fit the user's normal procedures can cause quality and productivity 
problems when the users are forced to change their procedures or when they 
ignore or misuse the CM system so that they can continue to use their normal 
procedures . 

1.4 APPLICABLE OPTION PAPERS 

The Software Development Option Paper, Section 3.5.2, identified four tools. 

It is felt that more tools will become available by the time it is necessary 
to procure one and it is more advantageous to trade characteristics of the 
tools to be procured than the tools themselves. 

1.5 ALTERNATIVES 

1.5.1 PROVIDE SINGLE PACKAGE 

This alternative would provide a single system to be used by all users. The 
user group with the most stringent control requirements would drive the 
definition of the requirements . Much consideration and coordination would 
have to be put into the requirements to best satisfy all the software 
developers . 

1.5.2 PROVIDE MULTIPLE PACKAGES 

This would involve analysis of user needs and the development of multiple 
different packages with varying level of control and variety of other 
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characteristics. Each user group would then select the one which most nearly 
fit its needs, and mold his CM activities to the options provided. For the 
purpose of quantification in the comparison of options, the specific number of 
packages provided was needed. Four were selected in the belief that it would 
be realistic in allowing sufficient variety of characteristics . 

1.5.3 PROVIDE TAILORABLE SYSTEM 

This option would provide a set of table driven functions. The tables would 
be controlled by a 'system administrator' within the user group. The system 
administrator would be required to define in the tables the specific options 
for his user group. Some potentially tailorable items include: 

o Control instrument definition 

o Board approvals required 

o Milestones tracked 

o Software elements controlled (e.g. source code, requirements , design, 
users guides, etc.) 

o Costing units (e.g. SLOCs, man months, memory requirements ) 

2 . 0 METHODOLOGY 

In order to evaluate the alternatives presented, criteria were established 
against which the alternatives could be measured. The criteria used are 
defined in "Trade Study Criteria". 

Next, in order to gain an understanding of user needs, a survey was taken of 
the configuration management procedures used on a number of NASA and DOD 
projects. Various generic documents and standards were also reviewed. A 
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summary of the major projects included is given in "Appendix A. Survey of 
Configuration Management Procedures". The following projects are included in 
the Appendix: 

SPACE SHUTTLE PRIMARY AVIONIC SOFTWARE SYSTEM (PASS) This project works for 
NASA's Johnson Space Center to produce the software for the Shuttle's Primary 
Avionics Software System (PASS). This covers three areas of responsibility, 
the PASS development, the support software and test tools development, and the 
verification of the PASS. 

SPACE SHUTTLE RECONFIGURATION DATA SYSTEM This system was developed at Johnson 
Space Center to support the generation, maintenance, and configuration control 
of data used by the PASS to support the various payloads. 

SPACE SHUTTLE GROUND BASED SUPPORT SYSTEM (GBS) This project is responsible 
for the generation and verification of the software which is executed in the 
Mission Control Center (MCC) and NASA's Johnson Space Center. 

SPACE SHUTTLE LAUNCH PROCESSING SYSTEM (LPS) This is the software responsible 
for controlling the Space Shuttle countdown and launch sequence. 

SPACE LABORATORY This is the project which generated the operating system for 
the experiment computer for the Space Laboratory at NASA's Marshall Space 
Flight Center. 

EARTH RESOURCES BUDGET SATELLITE AND GAMMA RAY OBSERVATORY Both of these 
projects were done at NASA's Goddard Space Flight Center and used the same 
Configuration Management system. 

Using the findings from the survey and an understanding of the Space Station 
generic requirements , the criteria list was revised and a weight proportionate 
to its importance to the project was assigned to each criteria. These weights 
are listed in Figure 2. 
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Each alternative was then evaluated to determine how well it would perform 
against the criteria. The results of this are documented in Section 3. A 
value was assigned to each alternative for each criteria to indicate its 
relative strength among the alternatives. See Figure 2. The relative 
strength was multiplied by the weight of the criteria and the products 
accumulated for each alternative to indicate the best selection among the 
alternatives. This is depicted in Figure 3. 

3.0 RESULTS 

The results of the Configuration Trade Study are summarized in Figure 2 and 
Figure 3. The first figure shows the criteria used, the weight assigned to 
each of the criterion (totals to 100), and the relative strength with which 
each alternative meets each criterion (also totals to 100). The second figure 
repeats the criteria and the weights, and replaces the the relative strengths 
with weighted strengths (the weight for the criterion multiplied by the 
relative strength of the alternative for the criterion). 

As can be seen in the referenced figures, alternative 1 has its greatest 
strength in the areas of cost and commonality while alternative 3 is strongest 
in adaptability, ease of use, and user acceptance. Alternative 2 tends to 
share in the weaknesses of alternative 1 without any great strengths to offset 
those weaknesses. 

The remainder of this section discusses the criteria as they apply to each of 
the three alternatives. Particularly emphasized are the strengths and 
weaknesses of each of the alternatives. 

3.1 ALTERNATIVE 1 - PROVIDE A SINGLE PACKAGE 

3.1.1 GENERIC 
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COST 


For this alternative, the implementation cost would be least. However the 
cost of defining the requirements and getting the users to approve them would 
probably be more than for the other two alternatives. The cost of maintenance 
would be similar in that the requirements approval could be tedious, but the 
actual implementation cost would be less than for the other alternatives. 

DEVELOPMENT TIME 


Like the cost, the impact of this alternative on the development time would be 
in the definition of requirements . More care would have to be given to 
defining the specific characteristics of the system to make it palatable to 
all users. The actual implementation of the requirements would be less for 
this alternative than for the others. 

TECHNICAL RISK 

This alternative would involve the least technical risk to implement. There 
would be no new technology required over what will be required for the 
communication of the data among the user groups, which will also be required 
of the other alternatives. 

IMPACT ON OTHER TOOLS 

The other tools would be least affected by this alternative. Each would have 
a consistent interface with the CM system. 

MANAGEABILITY OF DATA 


This alternative would provide a consistent definition of the data 
maintained. However, one group may decide to apply a different interpretation 
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Figure 2. Relative Comparison of Alternatives 
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Figure 3. Weighted Comparison of Alternatives 
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to some of the data than what is intended, to compensate for the lack of 
flexibility in the system. This occurred in one of the projects surveyed. The 
project had two different groups using the same system. One group wanted to 
record some data not provided for in' the system, so they began to use the 
fields in the data base that were defined for another purpose, but not used by 
them. This practice was done before documenting it through the requirements . 
Had they not updated the requirements to include the additional use, they 
would have run the risk of having undefined data in the data base. 

EASE OF USE 

The implementation of this alternative could be made as easy to use as the 
others, and easier to install (since there would be no decisions to be made at 
installation time). However, there could potentially be a learning curve for 
users to become accustomed to some of the characteristics which are new to 
them. For example, some development groups estimate cost in terms of source 
lines of code (SLOCs) and some use manpower (e.g. man months, weeks). Should 
all groups be forced to use the same units, the estimates for the groups which 
had to change could be inaccurate until they became accustomed to the new 
units . 

FLEXIBILITY 

This alternative would not be particularly flexible. Changes would generally 
require system updates, but the down time for installation would not be 
different than for the other alternatives. However, there could be potential 
problems in accessing data across user groups if one group were using a later 
or earlier SSE release than the others. 

3.1.2 TRADE STUDY UNIQUE 

AVAILABILITY OF DATA TO OUTSIDE USERS 

The CM data for one user group would be the most readily available to outside 
users if this alternative were implemented. This is due to the fact that the 
data and the software to access it would be the same across all systems, and 
no interpretation or conversions would be required. 
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SECURITY 


The data could be made sufficiently secure within a given user group. A 
subset of data from each user group would be made available to all users 
groups. This subset would have to be predetermined . 

USER ACCEPTANCE 

This alternative would probably be the least popular approach with the general 
users. Some of the users would feel unduly repressed by the level of control 
imposed on them by the system. If this were implemented, it would be 
difficult to encourage payload customers to use the system. 

ADAPTABILITY 

This alternative would not be particularly adaptable to user procedures. It 
would have to provide support for several procedures and methods for bypassing 
the ones the user did not want. If not implemented correctly, it could tend 
to dictate procedures. The quality of the software produced using this 
alternative could be adversely affected if too little control were implemented 
or, if too much control were implemented, productivity could be reduced. 

3.2 ALTERNATIVE 2 - PROVIDE MULTIPLE PACKAGES 

3.2.1 GENERIC 

COST 

For multiple systems, the requirements cost for the first system would be 
approximately the same as Alternative 1. Since the systems each have common 
elements that can be identified and reused, the cost of each of the remaining 
systems is approximately half of the cost of the first system. Both 
requirements and development cost follow this pattern. 


DEVELOPMENT TIME 

Since there will be many common, reusable elements between the systems, the 
development time will be considerably less than developing multiple complete 
systems, but will still be greater than Alternative 3. Even more time can be 
saved if the systems can be developed in parallel. 


7-18 



TECHNICAL RISK 

This alternative would have more technical risk than Alternative 1 due to the 
multiple systems being developed, but would have less risk than Alternative 3 
because each system being developed is not as complex as that alternative. 

IMPACT ON OTHER TOOLS 

This alternative is easy to interface with local tools because each user group 
will have a consistent interface with the CM system. However, there will be 
more local tools required in order to compensate for the differences in the 
multiple systems. Global tools will need to be restricted to some common set 
of data across the multiple systems. This data may be referenced by using a 
cross reference between the local name and the global name. 

MANAGEABILITY OF DATA 

Since each system is developed to closely meet the local user's needs, this 
user should have no trouble in managing data. However, the global user may 
have difficulty in locating data required for reports. Also, data items 
between systems may have different but similar meanings, making combinations 
for global reports more complicated. 

EASE OF USE 

Each system will be easy to use by the local user because it has been closely 
designed to meet their needs. However, the global user will have to be 
familiar with all systems in order to produce project level information. 

FLEXIBILITY 

The multiple system alternative is not flexible. Changes to each system would 
require system updates, but the down time would not be different than for the 
other alternatives. However, for multiple groups using the same system type, a 
potential problem exists if the user groups are using different versions of 
that system type. 
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3.2.2 TRADE STUDY UNIQUE 


AVAILABILITY OF DATA TO OUTSIDE USERS 

Since there will undoubtedly be differences between the systems and data names 
can probably not be held constant from system to system, some cross reference 
must be maintained for global users to use in finding data. One example of 
this may be in identification of change requests. CRs, PCAs, DCRs and ECRs 
may each be used by different systems to request software changes. Some cross 
reference should exist to correlate them when gathering data across systems. 
Also, a common set of data between systems should be defined. 

SECURITY 

For each system the data could be made secure within a user group. A subset 
of data must be made available to the global user from all systems. 

USER ACCEPTANCE 

This alternative will be easier to sell to the local user because it has been 
more closely developed to meet the local user's needs than Alternative 1. The 
global user may have some loss of control due to data differences between the 
systems . 

ADAPTABILITY 


Each system must be produced so that there is adequate control to ensure that 
the software is developed according to requirements and modifications to 
requirements . However, for the global user control, a minimum set of common 
control data should be required of all systems. 

3.3 ALTERNATIVE 3 - PROVIDE A TAILORABLE SYSTEM 

3.3.1 GENERIC 
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COST 


A tailorable CM system would be more expensive to build and maintain than a 
single non-tailorable system since the tailoring options add complexity. 
However, a single tailorable system would be less expensive than four 
non— tai lorable systems especially in the maintenance phase when the four 
systems began to diverge from their common base. The operations cost would be 
about the same as for the other alternatives. Any extra operational cost 
associated with a coordinator setting up the tailored system for a user group 
would be offset by lower costs for the general user of a system tailored to 
the user group. 

DEVELOPMENT TIME 

As with the cost, a tailorable CM system would take take longer to build than 
a single non— tailorable system because of the greater complexity of the 
tailorable system. Also, as with the cost, a tailorable system would not take 
quite as long to develop as several non-tailorable systems. But the 
difference in development time would not be as great as the difference in cost 
since increases in manpower would affect the required time more greatly for 
multiple non-tailorable systems than for a single tailorable system. 

TECHNICAL RISK 

The technical risk in building a tailorable CM system is greater than the risk 
in building non-tailorable systems due to the greater complexity of the 
tailorable system. 

IMPACT ON OTHER TOOLS 

With a tailorable CM system, local tools (i.e., those written by the user 
group for their use) would be easier to write and maintain since they would 
not have to sift through any data other than that used by and known to the 
local group. Global tools (those written for use by a large number of user 
groups; including TMIS) could be harder to implement since they could not rely 
on the same data being available in all user systems. To have any chance of 
wide use, global tools will need to be restricted to some common set of data 
(possibly using a cross reference between the local name and the global name). 
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MANAGEABILITY OF DATA 

With a tailorable CM system, global management of data could become difficult 
since each user group's CM system might have different data in it. This could 
be partially avoided by forcing some subset of the data to be common to all 
users. Even this could be made tailorable by providing a cross reference 
capability to allow that data to be called by different local names, but still 
be retrievable from outside the user group by a common name (for example, 
CR,PCR,SSCR are all kinds of change requests while DR, IR, PTR are all kinds or 
error reports). As long as tailorability is a goal, there will always be some 
data which is available in some user's CM system and not in other user's CM 
system. 

EASE OF USE 

A tailorable CM system would be very easy to use by the local users - they see 
only the data they care about and they do not see any other group's data. 

That same system might be hard to use by outside users wanting to extract data 
from it because of the same issues discussed in "Manageability of data". 

FLEXIBILITY 

A tailorable CM system should by its nature not need frequent system wide 
changes to records and fields in its database. In addition, a tailorable 
system should be more likely to have design characteristics (e.g., table 
driven) which would make it easier to modify if its capabilities need to be 
expanded . 

With a tailorable CM system, there would be a greater chance that different 
releases could be used simultaneously by different user groups. This in turn 
will allow system upgrades to be installed piecemeal and at the user groups' 
convenience, resulting in less total system down time than for a system which 
requires all groups to come down together for system installation. 
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3.3.2 TRADE STUDY UNIQUE 


AVAILABILITY OF DATA TO OUTSIDE USERS 

Assuming that some data is available in all user groups' instantiations of a 
tailorable CM system (either directly or through a cross reference) that data 
would be available to all users. Other data unique to a particular 
instantiation of the CM system might not be as easy to carry outside that 
version 

SECURITY 

With a tailorable CM system, both the level of security and the particular 
data items to which security applies should be selectable by the user group. 
This includes not only which users have access to the CM system, but also 
which users can update particular data items and which users can see 
particular data items (privacy). Because of this ability to tailor access to 
the database, this alternative would have the greatest security for the CM 
database and the data contained in it. 

USER ACCEPTANCE 

A tailorable CM system will be the easiest to sell to the user groups since it 
allows them the greatest control over their own procedures without the need 
for a lot of compromises to satisfy external groups. The more globally 
oriented groups (contract monitors, integration groups) may have a problem 
with some loss of control on their part. But this loss of control should be 
more than offset by the global groups' ability to hold the user groups more 
accountable for their actions (since the CM system can be tailored to match 
the user group's procedures, it can not be used as the scapegoat for missed 
schedules or poor quality). 

ADAPTABILITY 

A tailorable CM system would be very adaptable to user needs. Each user group 
should be able to tailor the system to fit their procedures and methodology 
for producing software. The only danger would be if the system could be 
tailored to have so little control that it adversely the quality of the 
produced software. This could be avoided by implementing the CM system to not 
allow tailoring outside of certain bounds or by proper management review of 
the options selected for an instantiation of the CM system. 
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4.0 CONCLUSIONS, RECOMMENDATIONS & REMAINING ISSUES 


This trade study examined three alternatives for providing a Configuration 
Management system for the SSE. 

1. Provide Single Package 

2. Provide Multiple Packages 

3. Provide Tailorable System. 

Several existing CM systems were surveyed to establish a knowledge base for 
evaluating the alternatives. The results of that evaluation are discussed in 
"Results" and shown in Figure 2 and Figure 3. 

The single system alternative would lead to the lowest cost system with the 
most data commonality. However, this would be achieved only after a drawn- 
out requirements phase, with much disagreement, and probably very little user 
acceptance of the final product. 

The multiple system alternative has no outstanding strengths and would likely 
have the highest cost. The requirements and user acceptance problems of the 
single system alternative would be only slightly improved by the four system 
alternative . 

A tailorable system has as its greatest strengths its flexibility, 
adaptability, ease of use, and expected user acceptance. The greatest 
weakness of this alternative is its technical risk, and this can be reduced by 
producing detailed plans and specifications before beginning implementation. 

The conclusion of this trade study is that the tailorable system alternative 
is the most promising. It offers a high degree of flexibility and user 
acceptance with only a slight increase in cost and technical risk. 
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Below is a review of the issues presented in Section 1.2 and the impacts of 
this study on those issues. 

1) Control Board Structure - A specific board structure has not been 
determined. Although a potential one was suggested, it is not known 
that it will be adopted. Nor is it known that all subsystems and 
customers will require the same level of configuration control. 
However, if the tailorable alternative is used then the board 
structure will not drive the software implementation of the CM 
system, nor will the implementation drive the board structure. 

2) Customer Use of the SSE — This issue has not been resolved by the 
trade study. Selection of the tailorable approach optimizes the 
flexibility, adaptability and ease of use which would contribute to 
the willingness of customers to use the SSE. However, the real issue 
not resolved is how to determine if a customer or subsystem is 
autonomous. A potential approach could be addressed by static 
analysis routines executed against the candidate autonomous software 
and by validity checks within the DMS . This issue must be addressed 
in the future. 

3) Security - No specific requirements have been defined and any of the 
three alternaives presented could provide adequate security. The 
recommended alternative represents the most likely method for 
accommodating the requirements when they are defined. 

4) Components Managed — Any of the systems discussed must support all 
software components managed. As more definition of the software 
components is available, the SSE must address configuration control 
of them. New approaches will be required to support some of the 
emerging technologies such as relational data bases and expert 
systems . 

5) TMIS Interface - The TMIS interface remains undefined. The CM 
alternative selected must address the TMIS when the interface is 
defined . 
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APPENDIX A, SURVEY OF CONFIGURATION MANAGEMENT PROCEDURES 


A. 1 ONBOARD SHUTTLE SOFTWARE 

The Onboard Shuttle Software project is composed of three areas: the Primary 
Avionics Software System (PASS), the Software Production Facility (SPF) which 
provided all the support software, and the Independent Verification and 
Validation. All three areas used the same configuration management system and 
special provisions were made in the CM software to accommodate uniqueness. 

A. 1.1 TYPES OF DATA STORED 

The Onboard Shuttle Software project uses two hierarchical data bases to 
manage its configuration. One contains the names of all systems, built or 
planned and data pertinent to those systems. All systems are included, 
whether for actual release to the field or for intermediate development. The 
other data base contains the control instruments and their data. The control 
instruments managed consist of: 

CR Change Request for FSW updates 

PCR Program Change Request for FSW updates 

SSCR Support Software Change Request for SPF updates 

DR Discrepancy Report for FSW errors 

SSDR Support Software Discrepancy Report for SPF errors 

HDDR Help Desk Discrepancy Report for commercial S/W, H/W errors 

SAS Software Approval Sheet for FSW patches 

When a user creates a control instrument, he must indicate the priority, need 
date and project milestone driving the need (e.g., a specific flight). The 
system stores the date of creation, and based on the type of control 
instrument, the list of control boards to review the instrument. The control 
boards, requirements analysts, implementers and testers review the control 
instrument, and make assessments. The control boards assign a current 
disposition and if required, a target date for the next review. When the 
control instrument is approved, it is assigned to be built on a specific 
system (or set of systems). The data stored in the data base as a result of 
the assessment includes: 
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o Documents affected 

o List of up to ten areas affected by the change 
o The duplicate/superseding/associated control instruments 
o The cost (man weeks) and target and actual completion date for 
requirements update 
o For each error (DR, SSDR) 

- Control instrument and development phase which introduced the error 

- System in which error was identified 

Activity which identified error (e.g. inspection, test) and which 
preceding activities could have identified the error 
o Verification cost (man weeks) and coordinator 

o CPU time and simulation time required for development and verification 
(itemized separately) 

o List of up to five areas responsible for implementation and coordinator of 
each. 

o Each module affected (per system) and for each module, the milestones 
listed in "Milestones Tracked"; names of the responsible analyst and 
programmer; number of source lines of code (SLOC) affected; change (in 
fullwords) of code, data and stack memory and accuracy of change; memory 
configurations affected (FSW only); manpower cost (man weeks) for analysis 
and implementation 

o Principal Functions affected and for each, the name of the responsible 
analyst; the manpower to verify principal function (man weeks); and names 
and status of the test cases required for verification 
o Date, status and destination of patches 

A. 1.2 TYPES OF DOCUMENTS TO BE UPDATED 

A large number of FSW documents are maintained under configuration control, 
including the Level A requirements , Level C design. Integrated Test Plan, Test 
Specifications, and the Flight Computer Operating System (FCOS) Users Guide. 
The documents maintained for SPF include the Level B requirements , and the 
Level C design. The configuration control of all of these is manual. The 
configuration control system has had some recent upgrades which enable it to 
manage documents, however, none have been rehosted to the system. 
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A. 1.3 MILESTONES TRACKED 

For each scheduled release, these milestones are maintained: 

o Build target and actual date 

o Build cutoff target and actual date 

For each module to be updated, the target date, revised date and status 
(uncomplete/complete) are maintained for the following: 
o Start work 
o Design draft 

o Design review 

o Design review complete 

o Design complete 

o Initial code complete 
o Code review complete 
o Code complete 

o Test spec complete 

o Test complete 

o Test component checkout 

A. 1.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

The review board hierarchy is depicted in Figure 4 and Figure 5. 

A. 1.5 AUTOMATIC VS. MANUAL ANALYSIS 

All of the software for the On Board Shuttle project is maintained under 
automated configuration control. Software modules to be updated on a given 
build must be scheduled in the data base mentioned above. The build tools are 
driven by the data base and verify that all the necessary approvals have been 
given before the updates for a module are incorporated into the baseline. 

None of the documents are currently under the automated system, however, it 
would be possible to use the system to maintain them. 


7-29 



NASA Boards 


Contractor Boards 


I OASCB | 

I Flight Software | 

| Change Control | 

I - Primary . |- - 

| - Backup | 

| - Engine j 

| Controller | 

I - etc . | 

* # 

. Orbiter Avionics 
. Software Control 
. Board 


#- * 

| SSD CCB | 

| Recommendation/ | 

| Assessment for | 

-| Primary S/W | 

| Changes | 

| - Impacts | 

| - Schedules | 

| - Deliveries | 

# # 

Spacecraft Software 
Division Change 
Control Board 


- -# 

I I 

•| RRB j 

I I 

# -X 


X X 

| T&O Board | 

| - Special | 

j Patches | 

j - MMU Element | 

| Schedules | 

| - Waiver Review| 

I — OR j 

| Disposition | 
x x 

Test and Operations 

Board 


* .x 

I I 

-I BCB | 

■I I 

X X 


X......... x I 

| SSD Management | | 

| - Contract | j 

j Control j x 

| - Schedules | 

| - Release | 

| Contents | 

x x 


Spacecraft Software 
Division Management 


Figure 4. Onboard Shuttle Control Board Structure (NASA Boards) 
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A. 1.6 METHOD USED FOR COSTING 

Costing is done by manual estimation. As mentioned above, costs for 
requirements generation, development and verification are recorded in man 
weeks. In addition, estimation of software changes are made in source 
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lines of code required and in change in fullwords of memory required for 
execution . 

A. 2 ONBOARD SHUTTLE RECONFIGURATION DATA 

This Configuration Management System is used to control the modification of 
payload reconf iguration data via Data Change Request (DCR) . The data is stored 
in units which are groups of category occurrences. A category is a template of 
related items and a category occurrence is one named set of data values for a 
given category. 

A. 2.1 TYPES OF DATA STORED 

DCR data stored is DCR number (assigned by the system), title, description, 
disposition commentary, entry date/time, change date/time, originator, 
organization, phone, and DCR Coordinator identification. 

Additional information stored is master data base of all category occurrences 
or mission data base of mission specific category occurrences, list of units 
and categories authorized for modification, and list of units and category 
occurrences modified. 

Authorization data is stored for each user indicating categories for which 
data may be entered and/or whether or not the user is a DCR Coordinator. 

A. 2.2 TYPES OF DOCUMENTS TO BE UPDATED 

There are no referenced documents managed. All DCR's and data are kept online 
and may be viewed at any time by anyone with access to the system. If printed 
documents are required, they can be printed at any time. 

A. 2.3 MILESTONES TRACKED 

Board status of DCR is tracked as open, approved, withdrawn, or disapproved. 
Status of category occurrences are tracked as working or frozen (all data 
values within tolerances). 

A. 2. 4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

Internal review of payload data with payload supplier. DCR's are 
dispositioned by the Orbiter Avionics Software Control Board (OASCB). 
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A. 2. 5 AUTOMATIC VS. MANUAL ANALYSIS 

OCR ' s are created online by anyone who has access to the system. In order to 
have a OCR number assigned a valid DCR Coordinator' s identification must be 
supplied. The Conf iguration Management system automatically assigns the DCR 
numbers . 

Each unit and category has valid suppliers of data assigned in the 
Configuration Management system. These suppliers, once a category occurrence 
has been modified, are the owner of that occurrence and no one else can update 
that occurrence until the DCR is approved and baselined. 

When category occurrences are supplied, the potential supplier of category 
occurrences is automatically validated and if acceptable, may modify the 
data. After each category occurrence data is entered online, the data is 
automatically validated against predefined tolerances and if the data passes 
the tolerance tests then it is marked as a valid occurrence; otherwise, it is 
marked as invalid. 

After all category occurrences are entered, an integration processor is run in 
order to validate data across category occurrences. 

Once all authorized data has been entered into the system, the data 
occurrences are frozen by the data supplier or the DCR Coordinator which is 
automatically validated by the system. Only valid category occurrences can be 
frozen . 

After all category occurrence have been frozen, then the DCR Coordinator can 
submit the DCR for approval through the online system. 

Through the online system, the OASCB then dispositions the DCR. After 
dispositioning a baseline processor is initiated to make permanent updates to 
the system, if required. 
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A. 2. 6 METHOD USED FOR COSTING 

No costing methodology is supported by this system. 

A. 3 KENNEDY SPACE CENTER LAUNCH PROCESSING SYSTEM (LPS) 

The two components of the LPS that were surveyed were the Control Data 
Subsystem (CDS) and the Checkout Control and Monitor System (CCMS). The CCMS 
is the real time environment and distributed operating system for the LPS. The 
CDS is the off line system responsible for maintaining the large amounts of 
data required by LPS and generating executable data for the real time system. 

A. 3.1 TYPES OF DATA STORED 

The LPS system recognized the following types of control instruments: 

SPR Software Problem Report 

ESR Engineering Support Request (user generated) 

SESR Sustaining Engineering System Improvement Requests (contractor 

generated) 

CR/OSCR JSC Change Request (changes to KSC S/W generated by changes at JSC) 
IPR Internal Problem Report (problems initially documented by user) 

For each, the release affected, implementation phases, responsible department, 
affected modules, and documents affected were maintained in a data base. 

A. 3. 2 TYPES OF DOCUMENTS TO BE UPDATED 

The documents that were under configuration control were: 
o Users' Guide 

o Software Design Specifications 
o Software Interface Document 

o Programmers' Users Guide 

o LPS Standards 

A. 3. 3 MILESTONES TRACKED 

Milestones were tracked at three levels: high, mid and low. At the high 
level, for each ESR, SESR and CR, the origination date, need date, approval 
date of each board, release data, validation date, and the assessment date 
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were recorded. Release data was maintained at the mid level. Dates 
maintained were baseline complete, builds, integration start, validation 
start, and date to deliver to user. At the low level, for each module 
affected by a control instrument, completion dates were maintained for 
requirements, other documents, code and unit test. Dependencies were also 
recorded . 

A. 3. 4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

The control board structure used is depicted in Figure 6. The DL DED Board 
consisted of the NASA design group. It initially dispositions updates at a 
conceptual level. The ESR was a contractor technical board which reviewed 
control instruments, high level requirements and Engineering Assessments (ES) 
and recommended dispositions and implementation approaches. The Packaging 
meeting was attended by contractor management and systems engineers. It was 
at these meetings that release schedules and content were formalized and 
recommended to the DL DED for approval. Significant changes had to be 
approved by the NASA Level 3 Change Control Board. Following this, the 
functional groundrules and data flows were developed and presented to the 
Internal Contractor Panel and the NASA Design Panel for approval. After these 
approvals were given, the high and low level design and the error messages 
were generated and presented to the Internal Contractor and NASA Design 
Panels . 

A. 3. 5 AUTOMATIC VS. MANUAL ANALYSIS 

The software and the documents were managed by the system. Each line of 
software changed was associated with the authorizing control instrument. The 
builds were done automatically, using the stored configuration data. Regular 
reports were generated from the data base for tracking and status reporting. 
The data was also available on-line. 

A. 3. 6 METHOD USED FOR COSTING 

Change Assessments were made for each module affected by a control 
instrument. The units used were manweeks for software and pages for 
documentation. The effects of the change on CPU and disk utilization were 


7-36 



also estimated. Engineering Assessments were maintained for each department. 
They were generated by accumulating the change assessments, adding overhead 
for engineering and management, and converting documentation costs to dollars. 
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A. 4 SPACE LABORATORY EXPERIMENT COMPUTER 

This project was responsible for generating the operating system for the 
experiment computer for the Space Laboratory. The work wa 3 done by a 
subcontractor to the prime Space Laboratory contractor. 

A. 4.1 TYPES OF DATA STORED 

The types of control instruments maintained were: 

SOFTWARE CHANGE REQUESTS (SCR) - which were initiated by the subcontractor. 
SPACELAB SOFTWARE OPERATIONAL NOTES (SSON) - which document impacts and work 
arounds to existing SPRs. 

INTERFACE REVISION NOTICES (IRN) which were initiated by the prime contractor 
to document changes to external interfaces. 

ENGINEERING CHANGE PROPOSALS (ECP) — which are initiated by the subcontractor 
at the request of the contractor. 

SPACELAB PROBLEM REPORTS (SPR) - which are generated by users to document 
problems . 

If software impacts result from an IRN or an ECP, an SCR is generated. SCRs 
were dispositioned by the ICB and the SRB; the SSONs the SRB; the IRNs by the 
Contractor Control Board; the ECPs by the ICB, the Contractor Control Board 
and the CCB; and the SPRs by the ICB and the SRB. 

A. 4.2 TYPES OF DOCUMENTS TO BE UPDATED 

The documents that were maintained under configuration control were the 
Software Requirements Document and the Level B Spec. The Level C Specs were 
maintained, but not under configuration control 

A. 4. 3 MILESTONES TRACKED 

The milestones that were tracked were all at the release level. They were: 
o Development release to verification 
o Verification complete 
o Delivery to KSC 
o Test complete at KSC 
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A. 4. 4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

Four boards existed and not all boards were required to act on all control 
instrument type. The boards were: 

INTERNAL CONTROL BOARD (ICB) which consisted of S/W subcontract personnel 
only . 

CONTRACTOR CONTROL BOARD which represented the prime contractor. 

SOFTWARE REVIEW BOARD (SRB) which was chaired by the software contractor and 
had membership from the subcontractor, NASA Program Office and Payload Office. 

CHANGE CONTROL BOARD (CCB) which was chaired by the NASA Space Lab Program 
manager and was the highest level board. 

A. 4. 5 AUTOMATIC VS. MANUAL ANALYSIS 

The system used very little automation. Early in the project, the data was 
stored in a data base which had some report generation capabilities. This was 
discontinued later in the project. 

A. 4. 6 METHOD USED FOR COSTING 

Initial cost estimates were generated manually and expressed in manmonths for 
software development and pages for documentation. These costs were converted 
to dollars at the boards. 

A. 5 EARTH RESOURCES BUDGET SATELLITE AND GAMMA RAY OBSERVATORY 
A. 5.1 TYPES OF DATA STORED 

Data stored originates from the following forms: Configuration Change Request 
(CCR) , Component Origination Form (COF), Change Report Form (CRF) , Question 
and Answer Form, Review Item Disposition (RID) Form, and Specification 
Modification Form. 

The related types of data to be stored are project milestones and deliverable 

schedules, tests and test results, discrepancies and changes, specification 
modifications, questions to the requirements or development team, RID's, 
external data used for testing, and component development history. 


7-40 



A. 5. 2 TYPES OF DOCUMENTS TO BE UPDATED 

Documents to be modified are listed on the CRF . The usual set of documents 
under Configuration Management are functional specifications and requirements 
document, preliminary and detailed design documents, system description and 
user's guide, test plans, and development management guide. 

A. 5. 3 MILESTONES TRACKED 

The types of milestones to be tracked by this system are milestone and 
deliverable dates, date of reschedule, target completion or delivery date, and 
responsible person. 

A. 5. 4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

The Configuration Management Board Structure is responsible for approving and 
monitoring all items in a project that are under configuration control 
(usually these are projects that are related to mission support). 

There are two Configuration Control Boards: the Code 500 Board which 

processes Level 1 changes that have major effect on external interfaces, 
master schedules, or budgets and the Code 550 Board which process Level 2 & 3 
changes that have less significant or no effect on schedule or budget. 

A. 5. 5 AUTOMATIC VS. MANUAL ANALYSIS 

Three types of information are Configuration Managed: documents, software, and 
specific types of related information. System modifications are initiated by 
a CCR which are followed by a CRF or COF. 

Documents are manually tracked and monitored. When document changes occur, 
all concerned parties are informed. The primary purpose of the Configuration 
Management procedures is to ensure that there is a master copy of each 
document that reflects the current status of development and that change 
information is properly disseminated. 

Software is configuration controlled by the use of several libraries. Each 
programmer has a private library containing all of the software needed to code 
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and unit test. The software may be copied from the Controlled System Test 
Library (CSTL) into the private library for modification. This library is 
controlled by the programmer. 

After unit and preliminary integration testing is successfully completed, the 
software moves into the Controlled Integration Library (CIL) for system 
integration testing with the CSTL. When system testing is completed, the CSTL 
is modified by the contents of the CIL. 

When a build/release of the CSTL has been successfully system tested, it is 
copied into the Controlled Acceptance Test Library (CATL) for testing by the 
acceptance test team. 

Finally the modified elements are copied into the Controlled Operations 
Library (COL) for production use. 

When libraries are updated, only source code i 3 copied and then object and 
executable code is generated from the copied source. 


Certain specific types of related information are maintained such as developer 
questions . 

A. 5. 6 METHOD USED FOR COSTING 

The method used for costing is manmonths. 

A. 6 SPACE SHUTTLE GROUND BASED SUPPORT SYSTEM 

The configuration management system studied for the Space Shuttle Ground Based 
Support System (GBSS) project is used to maintain the application software for 
that project. Similar configuration management systems used by the GBSS 
reconfiguration and systems support groups were not studied. 

A. 6.1 TYPES OF DATA STORED 

Data is stored for two kinds of control instruments: Discrepancy Reports (DR) 

for reporting problems and documenting fixes to problems and Program Change 
Authorizations (PCA) for documenting other changes (upgrades) to the 
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software. The data below is carried in the GBSS DR/PCA database. Some of the 
data applies to both types of control instruments and some to only one. Most 
of the data originates on a paper form and is transferred to the DR/PCA 
database. 

o Originator information (name, address, phone, organization) 
o Problem Scenario (type of activity , date/time, hardware/software 
configuration) 

o Problem description (symptom, impact, analysis result, and fix 
description) 

o Supporting data (log tapes, dump tapes, attachments, references to other 
DR/PCA' s). 

o Affected area (department application area, and functional area) 
o Implementor (programmer initial, subcontractor ID) 
o Test case ID's 

o Documentation update status (whether or not updates are needed) 
o CSECTs updated 

o Closure code 

o Quality tracking data (software delivery on which problem introduced, type 
of error <data, requirements , interface,!, where it should have been found 
<detail design, code, IV test|, and cost to fix problem) 

A. 6. 2 TYPES OF DOCUMENTS TO BE UPDATED 

Various documents are maintained under configuration control and updates to 
documentation are required along with software updates. The DR/PCA database 
contains a flag indicating that documentation updates are required to 
implement the control instrument, but there is no indication of what documents 
are affected or when the updates are to be made. 

A. 6. 3 MILESTONES TRACKED 

The only milestones carried directly in the CM system are the target and 
actual dates for the control instrument to be ready for a build. Build dates 
and other development milestones are maintained manually outside the CM 
system. 
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A. 6. 4 CONFIGURATION MANAGEMENT BOARD STRUCTURE 

The major controlling group in the GBSS system is the management team. Changes 
to the system must be approved (signed) by the manager of the person making 
the update. Changes requested by the customer (NASA) are documented by TIRF's 
(Transmittal/Information Request Forms) which are agreed to and formalized by 
being signed by the appropriate manager. This control is exercised without 
any formal board. 

The Change Control Board (CCB) is made of of technical representatives from 
each application area. This board collects all changes to the system and 
ensures that they have proper management approval before allowing the updates 
to be submitted to the build process. 

A. 6. 5 AUTOMATIC VS. MANUAL ANALYSIS 

Control of what gets put into the system builds is done manually by management 
and area build input coordinators (the CCB). The system build process checks 
an Authorization Database built by the CCB before allowing an update to be 
made. 

A. 6. 6 METHOD USED FOR COSTING 

Costing is done manually. A cost for fixing problems is maintained in the CM 
system for use in quality measurements (the cost of making errors). This cost 
is maintained in manpower units (mandays, manweeks, etc.). 
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VIII. SOFTWARE SUPPORT ENVIRONMENT FACILITY 
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SOFTWARE SUPPORT ENVIRONMENT FACILITY TRADE STUDY 


1.0 INTRODUCTION 

1 . 1 BACKGROUND 

The purpose of this trade study is to identify and explore factors to be 
considered when deciding whether the Space Station Software Support 
Environment (SSE) is to be centralized or distributed facility. 

The scope of the SSE physically is nationwide. Special emphasis has been 
placed on 4 NASA centers : JSC, MSFC, GSFC, and LeRC with JSC Providing the 

lead role. The scope of the SSE technically is to support the complete range 
of software engineering functions from initial concept formulation to 
maintenance. Users will include commercial and academic customers building 
systems to checkout and control their experiments/payloads, single contractors 
building large computer systems such as the onboard operating system, and 
multiple contractors writing onboard and ground applications software. 

NASA desires the SSE to be the single environment for software development on 
the Space Station program. This is a cost saving philosophy. It recognizes 
the fact that a significant cost in the development of a complex computer 
system is the support environment in which the system is developed. Past 
programs have seen each NASA center (and often individual contractors) develop 
individual software development environments. This duplication and the 
unplanned and therefore complex interfaces between the environments has 
impacted the cost of maintaining these programs. 

Given that the SSE is common for all Space Station software development and 
given that this development effort will be a nationwide project, the question 
of facilities naturally arises. Is the facility one central NASA facility with 
remote workstations at each NASA and contractor site, or is the facility a 
network of smaller facilities at multiple sites? And if it is a network, is 
there justification for requiring each node to have compatible hardware? 

These are the questions addressed. 


RECEDING RAGE BLANK NOT PALMED 
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Several assumptions have been made and are specified here: 


1. The SSE will be contracted to a single contractor. This provides NASA 
with a single point of contact for SSE issues. The contractor will 
procure the software and hardware utilizing methods he deems appropriate 
(e.g., subcontracts, procurement) . This allows for the most cost 
effective SSE by maximizing exploitation of S/W and H/W commonality. 

2. In the case of the common distributed option the initial SSE hardware 
configuration will be provided to the centers along with the SSE software 
system. The size of this system will be based on the centers own 
specification of requirements to JSC. Subsequent changes to the 
configuration will be under the center's control. These would be changes 
such as the number of DASD's, printers, CPU's, etc. These changes would 
have to be made within compatibility specifications which would be the 
responsibility of the lead center. 

3. It is assumed that SSE support personnel would be provided at each major 
host facility. 

4. Workstations for the Space Station will be powerful desk top personal 
computers. The goal of the SSE will be that these intelligent work 
stations (IWS) will be able to perform many tasks themselves and also act 
as a terminal to the host processor to which it is attached. Ideally the 
user's interface will be the same wnether on an IWS or a "dumb terminal" 
attached to a host. 

5. The Phase B RFP stated that the onboard 0/S, NOS and User Interface 
Language will be a part of the SSE. It is assumed these and certain 
other user standard utilities (e.g.. Data base management system) will be 
provided in the SSE. 
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1.2 ISSUES 


The following are the significant issues addressed in this trade study. 

1) Procurement Process - The Phase B RFP states that the SSE contractor will 
procure the hardware for the SSE. However, the procurement strategy may 
be considerably different if the SSE is distributed among several NASA 
centers each using different hardware. 

2) Insertion of New Technology - Ada is the suggested language for the Space 
Station. Yet neither Ada nor any Ada Programming Support Environments 
(APSEs) will be very mature when the SSE is begun. Therefore it is 
crucial that the SSE be designed in a way that will facilitate upgrades 
of compilers and APSEs. Also, powerful software engineering tools are 
beginning to emerge. These should be provided to the software developers 
as they are available. 

3) Use of Intelligent Work Stations - This is the first major NASA project 
since the emergence of the IWS. The allocation of functions to the IWS 
and the interface between the IWS and host will play a vital role in the 
SSE. 

4) Use of the SSE by Customers - It is currently unclear the extent to which 
NASA will encourage/require commercial or scientific customers to use the 
SSE. If the customers are users of the SSE then the facilities must be 
made available to them in an efficient manner. 

1.3 TRADE STUDY CRITERIA 

The criteria used in this study are divided into two groups - generic and 

unique. The generic criteria are Cost, Risk, Performance, 

Standardization/Commonality and Growth/Technology Insertion Potential. The 

study unique criteria are Data Base Management and Processor Management. 
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1.3.1 GENERIC CRITERIA 


1 . 3 . 1 . 1 COST 

Costs related to this trade study include development and operational costs 
for the Space Station onboard and ground data management systems and the SSE 
itself. Distributed or centralized facilities will also have cost differences 
as functions of actual computing resources, communication, physical plant, and 
support services costs. Several elements of the cost criteria have been 
identified that point out differences between the three options. These are 
listed below: 


1. SSE procurement process — What agencies and procedures will be used to 
procure the initial SSE hardware and software. How will subsequent 
changes to the hardware and software of the SSE be handled. 

2. Initial SSE S/W development costs — How will the SSE be initially 
developed and what cost factors will be variable. 

3. SSE S/W maintenance costs - How will the SSE be maintained and what cost 
factors will be variable. 

4. Hardware costs - What factors will affect the cost of the hardware for 
the various SSE facilities options. 

5. System support personnel - What organization will the SSE system support 
organization take and how efficient and effective will it be. 

6. Physical plant - How will the buildings, rooms, A/C, operations etc, to 
support SSE facilities affect the cost of the SSE. 

7. Communications cost - How will communication costs for workstation usage 
and data transfer affect the cost of the SSE. 
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8. H/W and S/W recovery — Will the SSE design preclude the recovery of any 

hardware or software at the NASA sites for possible use in the SSE system. 

9. Software commonality - Will the SSE foster the "software factory" 

atmosphere required for effective reuse of Space Station software. 

10. Educational costs - How will teaching users and support personnel about 
the SSE affect the cost of the SSE. 

1.3. 1.2 RISK 

The risks associated with SDE facilities lie in 2 main areas: risks 

associated with providing and supporting of the SSE and risks associated with 

the use of the SSE. 

1. State of the art — What hardware and software technologies are required 
to develop each type of facility and how mature are they. 

2. Customer/Contractor acceptance of the SSE - Is there a risk that the 
customer and contractors will not utilize the SSE efficiently or react 
negatively towards software development methodologies supported by the 
SSE. How will the type of facility affect this risk. 

3. Control over the contractors - Will any type of facility gain NASA an 
advantage in the goal of trying to provide the minimum but necessary 
control over contractor generated software that will be developed on the 
SSE. 

4. Control over the customer - Will any type of facility gain NASA an 
advantage in the goal of trying to provide the minimum but necessary 
control over non-autonomous customer generated software that will be 
developed on the SSE. 
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5. Backup and recovery — What backup and recovery requirements are there for 
the SSE and does any type of facility address this process better than 
the others . 

6. Growth limitations - What are the chances of exceeding the limitations 
imposed by the SSE. 

7. Maintenance skills - Because of the long duration of the Space Station 
program, it is likely that the life span of the SSE will be 20 to 30 
years. Maintenance skills will be required to make needed software and 
hardware upgrades. How will the type of facility affect the availability 
of applicable skills. 

1 . 3 . 1 . 3 PERFORMANCE 

The performance of the SSE is a criteria with two viewpoints. One is the 
performance of the SSE in the task of supporting end users. The second is the 
performance of the SSE in supporting the task of integrating the end user's 
work products into their intermediate or final usable forms (i.e. a DMS memory 
load, a set of design documents, schedules, etc.) 

USER SUPPORT - User friendliness can be addressed by providing 
state-of-the-art tools to aid users in each phase of the software development 
process, by standardizing user interface techniques across SSE tools, 
providing on-line user documentation, tutorials and help information and by 
requiring fully interactive user workstations even for remote users. 

How a facility supports a user is a complex perception issue. Programmers 
notice response time and down time. Managers notice lack of control over a 
resource that is critical to their success. Initial impressions can go a long 
way towards user's ultimate acceptance of a system. Having a stable SSE 
available early on will be critical. The three different facilities options 
all have different effects on the following user support elements: 
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1. Perceived user friendliness - What factors about the three facilities 
options affect the views that the users have of the system. 

2. User control of SSE resources - Will users feel that they have any 
control over the SSE resources. Can additional capabilities and 
capacities be requested and received in a timely manner. 

3. Control over unauthorized use of the SSE - How will NASA control how the 
SSE is used. 

4. Support for site unique uses of the SSE - Will the various NASA sites and 
contractors be able to use the SSE for unique applications. 

5. Effectiveness of SSE support personnel - How successful will SSE support 
personnel be at solving user's problems. 

6. On-board use of the SSE — Will the SSE be able to support onboard users. 


INTEGRATION SUPPORT — The integration process occurs in all aspects of the 
software development effort: planning, scheduling, coding, testing, build, and 
release. Work products gathered in the integration activities includes 
programs, documentation, and status. Each step in the integration activity 
abstracts the input data to a higher level. The elements listed below will 
help determine which options facilitate the speed, ease, and effectiveness of 
the various integrating functions: 

1. Integration testing - How well does the SSE support integrated testing at 
the user's site and at NASA sites. 


2. Speed — How much time will be required to execute integration functions. 

3. TMIS interface. - How will the SSE support the TMIS interface. 
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4 . 


Communication and reviews - How well will the SSE support on-line 
documentation access, work product reviews, user to user communication, 
and standards definition and enforcement. 


1 . 3 . 1 . 4 STANDARDIZATION/COMMONALITY 

Standards and exploitation of commonality allow system designers to implement 
cost effective and growth oriented systems. 

1. Will any SSE facility option allow greater exploitation of commonality. 

2. Will standards be easier to define and enforce on any of the SSE options. 

1.3. 1.5 GROWTH/TECHNOLOGY INSERTION POTENTIAL 


The Space Station RFP emphasizes a design philosophy which allows for 
stepping up to advanced technologies as they become stable. This philosophy, 
if adhered to, will make the management of growth of the SSE and DMS as easy 
as possible. In thi3 section are the aspects of growth management that are 
affected by the type of SSE facility. They are: 


1. Limits - Are there any limitations on the growth of processing power, 
data communications or software function within the SSE. 

2. Technology insertion - Will the SSE design allow new technology insertion 
with minimum impact. 

3. Upwards Compatibility - Will there be upwards compatibility of hardware 
and software to facilitate growth of the SSE. 

4. Distributed intelligence - Will the SSE be adaptable enough to allow the 
integration of more and more intelligence into the environment. 
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1.3.2 TRADE STUDY UNIQUE CRITERIA 


1.3.2. 1 DATA BASE MANAGEMENT 

There will be many data bases created on the SSE. There is likely to be much 
interaction between these data bases. Sharing and communication of data 
between these data bases will occur within and between centers, contractors 
and customers. How the type of SSE facility affects this creation, storage, 
and sharing of data will be important. The following list is used to 
determine how well each type of facility supports the data management process: 

1. Data storage — How will the SSE handle data base management. 

2. Data sharing/integrity - How will the SSE handling the sharing of these 
data bases between users. How will the SSE ensure that all copies of 
data are the same. 

3. Security — How will the SSE ensure the security of these data bases. 

A. Backup and recovery — How will the SSE provide for backup and recovery of 

data in the event of a minor and catastrophic failure. 

1.3. 2. 2 PROCESSOR MANAGEMENT 

The CPU will be a critical resource of the SSE. How this resource is managed 
by the SSE will affect the user's view of the SSE. Insufficient processor 
power will result in slower response time for interactive users as well as 
lower total throughput. Total processing power is defined by peak demand. 
Security and backup configurations also must be considered. The following 
factors are affected by the facilities options: 


8-11 



1. CPU contention - How will the SSE handle the distribution of users across 
processors in order to optimize the resource and present the fastest 
response time to the interactive user and also optimize total job 
throughput. 

2. Handling peak demand - Will peak demand determine the size of the SSE. 

3. Backup and recovery - Will the SSE be designed to allow backup of 
processing in case of failures (including catastrophic failure). 

1.4 APPLICABLE OPTION PAPERS 

- 1.4.2 High Order Languages 

- 1.4.4 Advanced Tools 

- 2.1.1 Data Base Management 

- 3.5.2 Software Development 

- 3.5.3 Systems Integration Test and Verification 

1 . 5 ALTERNATIVES 

Three options for facilities are presented. The first option is a centralized 
facility with local and remote workstation access. The second option is a 
group of distributed facilities with a common hardware environment and common 
software. The distributed facilities would again be accessed via local and 
remote workstations. The distributed facilities would be networked together 
for the necessary integration functions. This option shall be called "common 
distributed". The third option is a group of distributed facilities with 
unique hardware environments. 


8-12 



1.5.1 CENTRALIZED SSE 


A centralized SSE would be located at the Johnson Space Center. Use of the 
SSE would be via workstations which could be located anywhere in the country. 
No limitation is set in this paper on the number or sizes of host processors 
which would accomplish this SSE. It is assumed that NASA would provide 
sufficient data communication and processing power to meet response time and 
throughput requirements of all users. This option is shown in Figure 1. 

Because of the distributed and hierarchical structure of SSE users, it is 
assumed that a corresponding structure would functionally exist in a 
centralized SSE. That is, individual users would promote work products 
(software, documentation, schedules, etc) up through higher and higher levels 
of integration. Different levels would functionally exist as separate users 
but physically might reside in the same processor. 

Testing of software products not designed to be executed in the SSE would 
either be done in the SSE via simulation or the software loads would be built 
in the SSE and electronically delivered to a user test set for execution in 
the target environment. Operational software loads would likewise be built 
and delivered. 
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Figure 1. The SSE as a Centralized Facility 
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1.5.2 COMMON DISTRIBUTED SSE 


Once the decision is made to have a distributed SSE/ the question "how 
distributed?" naturally arises. This alternative provides for distribution of 
compatible host hardware and common software at multiple sites. The functions 
provided are similar to those in the central SSE option, but are augmented 
with communicaton functions between facilities. The lead facility would be at 
JSC. The user interface to the facilities will be either IWS or "dumb 
terminals." The number and locations of facilities will depend on the 
distribution of work to be done. All software and hardware will be Government 
Furnished Equipment (GFE) . Figure 2 depicts one possible distribution. 

All host processors and workstations in this option are compatible H/W systems. 
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1.5.3 UNIQUE DISTRIBUTED SSE 


Most NASA software contractors have developed software engineering 
methodologies with which they are familiar and comfortable. These 
methodologies are often tied to a certain H/W system. The unique distributed 
option addresses this fact. 

This option allows unique systems at each of the distributed sites within the 
NASA. A formal Interface Control Document (ICD) would define the interfaces 
(i.e., format of products delivered) between the various facilities with the 
lead facility at JSC. 

Each facility would have the freedom to select the hardware and software 
products which would be most compatible with their installed base thus 
minimizing their individual initial cost and training requirements. 

Although the hardware/software at each individual center could be different 
all SSE functions would be supported in a transparent manner at the program 
level. These functions include integration, CM, build, delivery, DMS user 
services, standards enforcement and integrated and system level testing. 

Data maintained on these unique local facilities would not be easily 
interchangeable among users. Special SSE services would be provided to support 
this data interchange if required. The facilities would be accessed via local 
and remote workstations and would be networked together. This option shall be 
called "unique distributed". 
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Figure 3. The SSE as a Distributed Network of Incompatible Systems 
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2.0 METHODOLOGY 


This trade study is based on surveys of past NASA software development 
environments, research into the current literature, interviews with users and 
developers of software development environments, interviews with software 
development managers, interviews with large computer system engineers, and the 
author's experience base. 

Appendix 1 contains a summary of some of these surveys. 

3.0 RESULTS 

3.1 COST COMPARISONS 

3.1.1 CENTRALIZED SSE COST 


A centralized SSE would have a centralized procurement process. This single 
agency would be responsible for the host computing facility. This agency 
would have to respond to all centers' changing requirements for SSE resources 
and as much as possible provide the optimum configuration at all times. This 
could require trading off resources among user groups taking into account 
various work loads and schedule constraints. This process is very susceptible 
to intercenter rivalries which might cloud true resource needs and result in 
unfair and inefficient SSE resource management. 

The following areas affecting cost of the SSE would be minimized with a 
centralized SSE : 

1. physical plant - buildings, rooms, A/C, power, etc. 

2. system support personnel - operators, system engineers, help desks, etc 

3. educational costs 
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To minimize the software development costs for Space Station, the SSE must 
provide an environment which supports a software factory atmosphere. The 
generation of reusable software components must be emphasized and supported by 
the SSE. A mechanism must be provided to aid the user in finding reusable 
software when the SSE is queried about it's existence. A centralized SSE host 
facility would allow a program library structure and access methods which 
could optimize the reuse of previously designed, coded, and tested software 
components. Maximizing this advantage however would required similar 
development methodologies and effective standards definition and enforcement 
across all space station software development efforts. 

A disadvantage of a centralized SSE would be in the area of H/W and S/W 
recovery at the various NASA sites. Currently existing facilities that might 
be available for Space Station software development use might not be usable 
because of incompatibilities. 

Communication costs would be higher for a centralized SSE facility, but it is 
not felt that this factor would be significant. Communication costs are 
falling and also NASA could possibly utilize some of its existing networks. 
Most users would require long distance access for workstation sessions but 
there would be no need for long distance communication during integration 
processes. Many advances are currently being made in the area of devices to 
cluster remote workstations and provide very efficient sharing of 
communication lines to the central facility. 

There will be much use of the SSE for documentation storage. For documents 
that must be available at all sites such as user documentation, tutorials, and 
on-line HELP functions, a centralized SSE will minimize the cost for DASD to 
store this type of data. 
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3.1.2 COMMOW DISTRIBUTED SSE COST 


Given assumption 2 in section "Background" the initial procurement of even the 
common distributed SSE would be handled by a single agency thus minimizing the 
procurement overhead. However, total processing power required by all 
distributed locations might total to greater than the central SSE in order to 
handle peak conditions at each center separately. Costs for multiple copies 
of commercial software for the SSE can be minimized with commercial licensing 
agreements . 

Greater costs would be incurred because of the multiplicity of physical plants 
and system support environments. 

A common distributed SSE could also be designed to support the software 
factory environment effectively. And, there would be more of a chance for 
centers to reuse currently existing or newly developed hardware and software. 

Most terminal usage would not require long distance costs in a common 
distributed SSE but integrating functions would require burst of long distance 
communications . 

3.1.3 UWIQUE DISTRIBUTED SSE COST 

The advantage of the unique distributed SSE is that each site could retain 
expertise and support software gained in various software development 
environments and methodologies. This could be an initial cost savings but is 
questionable on a life cycle cost basis. Ada is the proposed language for 
most of Space Station development efforts and the cost of multiple versions of 
the Ada programming support environments would outweigh benefits of using the 
installed hardware base. It would also complicate a software factory 
environment. 

Another disadvantage is that several contracts would be required to develop 
the SSE due to the diversity of system architecture desires at each center. 
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If this alternative were selected, a funding reallocation would be necessary 
to provide funds for the support and maintenance of the local systems by the 
individual NASA centers. 

As in the common distributed SSE option, there would also be the extra cost of 
maintaining multiple sets of physical plants and support environments. 
Educational costs would be much higher with multiple software development 
environments to teach. No common Space Station software development culture 
would be formed. This would hinder NASA's goal for the lowest possible 
software life cycle costs. 

3.2 RISK COMPARISONS 

3.2.1 CENTRALIZED SSE RISK 

SSE development risk is minimized in a centralized SSE. This is a mature 
hardware conf iguration and would allow the simplest SSE software system. 

There is a real risk of poor user acceptance of a centralized SSE. An 
efficient, standard development environment if not used effectively will not 
address S/W life cycle costs as predicted. 

On the other hand a centralized SSE maximizes NASA control over contractors 
and customers. 

A centralized SSE runs the risk of large numbers of users left stranded when 
processors go down. A catastrophic failure could mean no SSE services for a 
protracted time period. 

3.2.2 COMMON DISTRIBUTED SSE RISK 

A risk exists in designing a common distributed SSE because of the immaturity 
of the technology. This is not felt to be a significant risk however, Areas 
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of immature technology are mostly limited to distributed data bases. 
Constraints because of these limitations would not significantly impact the 
design of a common distributed SSE. 

The risk of user rejection of the SSE is smaller with a common distributed 
SSE. It is felt that the presence of local facilities will be seen as a 
positive effect. It will allow the user to have more control over the SSE 
resources . 

Multiple SSE facilities will allow each NASA center effective control over 
their contractors and customer generated software. 

A common distributed SSE has the ability to address the risk of failure of the 
individual SDE facilities. If deemed necessary, the overall architecture 
could allow facility sites to serve as backups for other facility sites. 

3.2.3 UNIQUE DISTRIBUTED SSE RISK 

A unique distributed SSE limits the risk of user acceptance of the SSE. With 
a familiar environment the user is likely to feel more comfortable. Initial 
software development in languages supported by the existing environments would 
also be more efficient. However adoption of Ada would obviate the advantage. 

There is a risk in developing the interface between the various facility sites 
and the lead facility at JSC. It may be difficult to implement the electronic 
interface between incompatible hardware . (See RNET in Appendix) There is 
also a risk in defining an incomplete or ineffective ICO which will require 
modifications resulting in software impacts at the various facility sites. 

The risk in a unique distributed SSE relates to the total life cycle costs 
associated with software built in this environment. Commonality across the 
project would not be exploited. Standards would not easily be applied in the 
different environments. 
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There is a risk that if the DMS user services are provided only at the 
integration level, users, both contractors and customers, may choose to 
develop unique code rather than use some of the DMS services. If this 
happened, it would increase cost of the program and effect the capability for 
technology insertion. 

Unique environments would not allow for the backup facilities by facilities in 
other locations in the event of failures. 

3.3 PERFORMANCE COMPARISONS 

3.3.1 CENTRALIZED SSE PERFORMANCE 

3. 3. 1.1 USER SUPPORT 

User support is viewed from the perspective of each different type of user. 
Many users are day to day interactive terminal users. Many other users will 
utilize reports and documentation in an off-line environment. In general 
off-line users should be unaware of whether the SSE is centralized or 
distributed. On-line users can also have a transparent interface to the 
facilities with appropriate attention to this factor during the SSE design. 

For long distance real time users to have a positive perspective of a 
centralized SSE, appropriate attention will have to be spent on acquiring 
reliable and fast communication links. This should not be a problem however. 

Another important factor affecting the usability of a system is the perceived 
control a user has over the resource which is critical to the successful 
completion of his or her task. A centralized SSE may cause the feeling in 
users and managers of users that it will be too difficult to address problems 
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with the resource. At one extreme, many more levels of control and therefore 
more justification and effort will be required to add capacity or capability 
to the SSE if deemed necessary by a remote site. At the other extreme, single 
users with daily problems may find long distance help unsatisfactory. 

However, by centralizing the system support activity and providing enhanced 
communication capabilities, a more efficient and effective system support 
organization might result. 

A centralized SSE would minimize the ability of remote sites to make unique 
uses of the SSE. Site unique applications within the SSE system itself would 
be requested of the lead center, reviewed for true uniqueness, and eventually 
delivered. Site unique uses of the SSE computing hardware would not be 
possible. This would eliminate any "hands-on" type operations such as 
required in some testing situations. 

A centralized SSE could support on-board use of the SSE as well as any other 
option. 

3. 3. 1.2 INTEGRATION SUPPORT 


A significant advantage of the SSE over software development in past NASA 
programs will be the ease with which the SSE will allow intercenter 
communication, review, requirements and interface specifications, and 
standards definition and enforcement. This support is optimized in a 
centralized SSE. Documents for communication and review are on-line and 
available to all users at all sites with small time delays and simple 
procedures necessary for routing them between centers. 

The time required to execute all integrating functions would be minimized in a 
centralized SSE. The procedures for promoting all types of work products 
(i.e. programs, test cases, designs, schedules, etc.,) to higher levels for 
integrated activities would be simpler and faster to implement and execute in 
a centralized SSE. 
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The TMIS interface is not well understood. There are no apparent advantages in 
a centralized SSE to the TMIS interface other than providing one source for 
acquiring data that needs to be transferred to the TMIS. 

3.3.2 COMMON DISTRIBUTED SSE PERFORMANCE 

3.3.2. 1 USER SUPPORT 

A common distributed SSE probably has the best chance of optimizing both 
perceived and real user support. Most problems with long distance usage would 
not be a factor - although because of the geographical distribution of SSE 
users even a common distributed SSE would have many remote users. 

With the SSE facility local to each site, users will have more control over 
the resource. More capacity could be added without intercenter justification. 
More capabilities could be added in two ways. First, "official" SSE 
capabilities would have to be requested of the lead center and delivered at a 
later date. Other applications, as long as they met standards, might be added 
by the sites for unique processing. A local SSE would allow "hands-on" 
operations if necessary. Systems support personnel would be closer at hand in 
a common distributed SSE to provide a more effective assistance function. This 
assumes that the support function resource is addressed properly and not 
diluted by the distribution of the SSE. 

More effort and resources would be necessary to maintain security in a common 
distributed SSE. Much data would be transferred between sites. Security 
efforts might be less effective when handled by many agencies as opposed to 
just one. The advantage of allowing site unique uses of the SSE brings the 
disadvantage of possible unauthorized or inappropriate uses. 
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3. 3. 2. 2 INTEGRATION SUPPORT 


Intercenter communications and reviews (for requirements and interface 
specifications, standard definition and enforcement, etc) could be well 
supported by a common distributed SSE. The logistics and the procedures for 
gathering the data would be more complicated and time consuming than a 
centralized SSE, but still very practical considering the advantages of this 
type of communication. 

Other integrating functions such as system builds, planning, scheduling, and 
configuration management would also be slower because of the gathering of data 
required from the remote hosts. Procedurally however, this is not a 
significant factor. 

Support for the TMIS interface would be similar to a centralized SSE. A 
common distributed SSE might facilitate the THIS interface if NASA managers at 
the sites require site SSE data - the data would not have to be processed 
through a centralized interface. 

3.3.3 UNIQUE DISTRIBUTED SSE PERFORMANCE 

3. 3. 3.1 USER SUPPORT 


User support in a unique distributed SSE would appear similar to a common 
distributed SSE as far as availability, support and site control over the 
resource. However, the SSE system provided to run on the distributed 
facilities might be limited in function compared to a centralized SSE or 
common distributed SSE. A robust, project wide tool set for software 
development would not be attainable because of the incompatible environments 
of the various machines. 
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System support personnel at various facilities would not be able to "compare 
notes" and would minimize the possibility of learning from other center's 
experience base. Users would have to be educated both on their systems and 
also on any integration system that they used. 

3. 3. 3. 2 INTEGRATION SUPPORT 

A unique distributed SSE would complicate the integrating functions of the 
SSE. This is the point where all sites have to communicate and share data and 
procedures. Incompatibilities in the SSE' s will be a factor here and will 
have to be overcome during integration activities. Data bases will have to be 
made consistent, communication procedures will have to be designed, and data 
will have to be converted to similar formats. Not only will data formats be a 
problem but networking different systems presents significant communication 
problems (see RNET in appendix). These problems will cause integration 
functions to be harder to design and maintain. 

3 . 4 STANDARDIZATION/COMMONALITY COMPARISONS 

3.4.1 CENTRALIZED SSE STANDARDIZATION/COMMONALITY 

A centralized SSE addresses both standardization and commonality well. 
Compatible hardware and software systems would allow for commonality of data 
bases, communication, development methodologies, procedures, terminology, and 
training across all users of the SSE. This commonality would foster creation 
of a Space Station software engineering culture which would enhance NASA's 
program management task. 

3.4.2 COMMON DISTRIBUTED SSE STANDARDIZATION/COMMONALITY 

A common distributed SSE has all of the advantages of standardization and 
commonality as described above for a centralized SSE. 
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3.4.3 UNIQUE DISTRIBUTED SSE STANDARDIZATION/COMMONALITY 


Many advantages of commonality would be lost in a unique distributed SSE. 

With various software engineering methodologies in place, a common experience 
base of procedures, terminology, problem resolution and training would be 
lost. No global Space Station software engineering culture would be created. 
This would affect Space Station software life cycle costs by requiring 
operational contractors to learn multiple software development methodologies. 

3.5 GROWTH/TECHNOLOGY INSERTION POTENTIAL COMPARISONS 

3.5.1 CENTRALIZED SSE GROWTH/TECHNOLOGY INSERTION POTENTIAL 

A centralized SSE represents a possible growth limitation problem when 
compared to a distributed SSE. A centralized design might become cumbersome 
if the number of users grows much larger than the number for which the SSE was 
originally designed. A important factor likely to affect this limitation is 
the evolution in integrated workstation products occurring now. Powerful 
workstations, compatible with mainframe processors, are becoming available. 
Response time issues can be addressed by this technology. Growth is 
accommodated not only by adding to the central host complex but by adding 
workstations. This technology will evolve the SSE from a centralized facility 
to a distributed one. A real danger exists then that an initial centralized 
philosophy for the SSE would limit the effectiveness of IWS 1 s and local area 
networks of IWS's. 

A centralized SSE allows SSE developers to ensure the H/W and S/W is designed 
for upward compatibility to allow for significant growth with minimum impact 
to the SSE system software. 

Another advantage of a centralized SSE is that one agency would be responsible 
for controlling growth. This agency would have more power than multiple site 
oriented agencies. This agency could attempt to optimize SSE resources across 
all sites for the most cost effective growth management. 
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3.5.2 COMMON DISTRIBUTED SSE GROWTH/TECHNOLOGY INSERTION POTENTIAL 


A common distributed SSE has the best chance of eliminating limits to growth. 
•The nature of the design for a common distributed SSE would lend itself to 
adding or subtracting distributed host facilities with minimal impact to users 
and the SSE system. Existing facilities could expand processor capacities 
with a smaller risk of meeting some unexpected upper limit to growth. Upward 
compatibility of H/W and S/W here would have to be a part of the SSE design. 

A growth in communication rates for the distributed network would be another 
factor in growth management. A risk would exist here that the initial design 
of the common distributed SSE might not take into account all necessary data 
communication and growth might become difficult and expensive. A common 
distributed SSE implies a growth management function being performed at each 
site. Current technology however, supports a centralized network management 
function which can automatically collect information from distributed nodes to 
allow growth management from a central agency. 

3.5.3 UNIQUE DISTRIBUTED SSE GROWTH/TECHNOLOGY INSERTION POTENTIAL 

Limits to growth for the unique distributed SSE are again similar to the 
common distributed SSE. Growth in a unique distributed SSE is liable to 
impact more SSE software than in the other two options. This is because it is 
anticipated that more custom SSE software will be required in a unique 
distributed SSE to handle functions for which common or centralized SSE ' s 
might be able to use commercial software. Network management in a unique 
distributed SSE could not be performed by a lead host. This would impair any 
centralized growth management functions. 

3.6 DATA BASE MANAGEMENT COMPARISONS 

3.6.1 CENTRALIZED SSE DATA BASE MANAGEMENT 

A centralized SSE enhances data base management throughout the SSE. All data 
bases would exist side by side, structured alike, thereby aiding any 
integration of 
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the data from the different data bases. Security is enhanced, data does not 
have to leave the facility to be shared, although it still leaves the facility 
for user access via reports or terminal viewing. Data integrity is enhanced 
by the lack of duplication of data which could allow copies to get out of sync. 

3.6.2 COMMON DISTRIBUTED SSE DATA BASE MANAGEMENT 

A common distributed SSE enhances data base management through the use of 
consistent data base structures. Sharing the data is slightly more difficult 
than a centralized SSE but could double as a means of backup for other site's 
data bases. Security is a consideration since sharing data would require 
transmission from site to site. Currently there are no mature distributed 
data base management systems. Constraints on the SSE design would be required 
to assure this immature technology does not affect the SSE adversely. 

Therefore data base management in a common distributed SSE would actually be 
unique independent data bases at each node. Interchange of data therefore 
would be through custom generated procedures. 

3.6.3 UNIQUE DISTRIBUTED SSE DATA MANAGEMENT 

A unique distributed SSE could support data base management within each 
facility satisfactorily. However, sharing data and handling other sites data 
would require significant special processing (see RNET is appendix). Security 
would be affected as in a common distributed SSE. 

3.7 PROCESSOR MANAGEMENT COMPARISONS 

3.7.1 CENTRALIZED SSE PROCESSOR MANAGEMENT 

A centralized SSE would in reality be multiple processors. CPU contention 
would be controlled by the SSE to present a fair response time to all users. 
Total processing power would be a function of peak use including all 
interactive users, simulations, and integrated testing. 
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A significant disadvantage of a centralized SSE is that if processor support 
is lost, all users will be left unsupported. If this loss is due to a 
catastrophic failure, then the SSE would not be available for a long time. 

This may not be acceptable with a manned Space Station to support. 

3.7.2 COMMON DISTRIBUTED SSE PROCESSOR MANAGEMENT 

A common distributed SSE has the advantage that not all users are on the same 
facility and a failure will therefore affect a smaller number of SSE users. 

If desired the common distributed SSE could be designed to allow sites to 
provide backup support for other sites in case of failures. 

Total processing power in a common distributed SSE might be larger than in a 
centralized SSE because each site would have to be able to react to it's peak 
load conditions that if added to all other sites and spread out over time 
could be less for a centralized SSE. A common distributed SSE does not allow 
for "sharing" of resources. For example, if one center runs out of a 
resource, it may require a long time to procure more of the resource. However 
in a centralized SSE the resource would be shared equally with between centers 
until more can be procured. 

3.7.3 UNIQUE DISTRIBUTED SSE PROCESSOR MANAGEMENT 

A unique distributed SSE would handle processor management in much the same 
way as the common distributed SSE. However, the ability for one site to be 
used as a backup for another site would be severely limited. 

4.0 CONCLUSIONS, RECOMMENDATIONS & REMAINING ISSUES 

Based on the summary of advantages and disadvantages in Figure 4 the 
recommendation is that a distributed SSE of compatible hardware and software 
would be most effective at both supporting the user and providing NASA with a 
means to address software life cycle costs. 


8-32 



Workstations on the end user's desk will address his or her productivity. A 
small host integrating many local users at the contractor's site will support 
testing, communication among users, and data sharing and will allow software 
managers to effectively use the SSE for project management and configuration 
control . 

Larger hosts at NASA centers will support effective NASA project management, 
the TMIS interface, and higher level of integration functions, system builds 
and deliveries. 

All levels of hardware from the desk top to NASA centers should be compatible 
hardware systems with a user interface standardized by the SSE system which 
resides at each level. This hardware and software compatibility along with 
the design philosophy of a distributed SSE will give NASA the best control 
over growth, technology insertion and standards. This commonality approach 
will encourage the formation of a Space Station software development culture. 
With similar experience bases because of the common methodologies, procedures, 
interfaces, data bases, etc users will find it easier to communicate and work 
with peers, integrators, and managers. NASA will find it easier to manage the 
software from development through operations and maintenance. 

Below is a discussion of the issues identified in Section 1.2 and how the 
recommended approach addresses them. 

1. Procurement Process - If the common distributed alternative were 
selected, then each host site would be provided with its initial system. 
Then each site would be responsible for procuring additional hardware 
capacity as needed. 

2. Insertion of New Technology - The adoption of the common distributed 
alternative would allow the SSE contractor to incorporate new software 
technology and distribute it in normal SSE system releases. Use of 
compatible hardware makes upgrades to more advanced hardware more 
efficient than using mixed hardware would. 
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3 . 


Use of IWS - By having common software and compatible hardware, the 
possibility of providing a common interface to the user from both IWS and 
terminal is greatly enhanced. It is recognized that many IWSs are 
available and customers may want to interface with the hosts from a 
variety of IWS's. Using the common software and compabile hardware 
throughout the SSE will minimize the difficulty of effecting the 
interface . 

A. Use of the SSE by customers - It is believed that selection of the common 
distributed alternative would not discourage customers from using the 
SSE. The availability of the DMS user services in the SSE will make it 
attractive for them to use. Selection of this alternative for the SSE 
for contractors should not preclude the use of a modified "common 
distributed" approach for customers. They could use their own 
environments for their development, deliver their software to a NASA 
site, where they would test it and then make it available for integration 
and delivery to the vehicle. 
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01S/102 b/2 Figure 4. Criteria summary, weight factors, and advantages 
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6.0 APPENDICES 


6.1 SPF 


JSC's SOFTWARE PRODUCTION FACILITY (SPF) FOR SHUTTLE 

The SPF is a centralized software development facility at JSC used for 
development, test, release, build, and CM control of Shuttle Primary Avionics 
Software and the SPF software and the verification testing of the Backup 
Flight Software (BFS). Users are local at JSC and remote at Rockwell in 
California for the Backup Flight Software, and remote at various other NASA 
centers such as KSC. 

Problems with remote use of the centralized SPF have centered around a lack of 
common culture among the users and the difficulty of users communicating with 
SPF support personnel over long distances. The remoteness adds a level of 
complexity which increases the time needed to solve problems. Telecons have 
been utilized to address the problem but are impaired by the logistics of 
getting the right people in attendance and the time zone difference. 

An important point for Space Station software development is that at least 
during the maturing phase of the SSE support personnel must be readily 
available to the end user. This can be accomplished by direct support at the 
remote host sites or greatly enhanced video conference capabilities (i.e. 
listing and dump availability). The SPF is a custom developed software 
development environment hosted on IBM 3033 and IBM 3084 mainframe processors. 
Some commercial products have been incorporated into this environment. Because 
of its complexity it took a significant time period to achieve maturity. 

During this time period, support for users was not optimum and productivity 
suffered. The Space Station SSE should be created using as many commercial 
products as possible in order to achieve maturity quickly and support user 
productivity . 
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6.2 LPS 

KSC's SHUTTLE LAUNCH PROCESSING SYSTEM (LPS) 

LPS has two major software development environments. Programs developed for 
the off-line Central Data System(CDS) are maintained on Honeywell 6600 
mainframes. Programs developed for the on-line Checkout, Control and Monitor 
System (CCMS) are maintained in a specialized configuration of the target 
machine hardware - Modcomp minicomputers called the Software Development Lab 
(SDL). Both environments were custom generated and are centralized facilities. 

The current contractor (Lockheed) is experimenting with a network of Apollo 
supermicros to decentralize and consolidate the two environments. User 
workstations and windowing are being used to greatly increase user 
productivity. Workstations are planned for software development, unit testing 
and some integration testing. 

6 . 3 RNET 


RECONFIGURATION NETWORK (RNET) 

The RNET project is addressing a problem that NASA has with the Shuttle 
program because of the multiple incompatible software development environments 
which were used to develop major Shuttle software subsystems. The 
incompatibility of data bases and communication protocols between these 
systems presents a severe hindrance to Shuttle software maintenance in the 
operational era. 

Twenty reconf iguration products such as the mass memory load tape have been 
defined as candidates for automatic transfer among the SPF, MCC, KSC CDS, and 
SRS . Problems being encountered include a lack of true cross vendor 
communication packages and the customized processes needed at each node to 
handle the data being automatically delivered. 

These experiences support the arguments in this trade study for the SSE being 
a system of compatible hardware and software systems. 
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